Service to manage configurations provided dynamically to end-user applications.

Requirement

Home page and product pages are crucial landing aspects for e-commerce customers. Continuous evolution of the user experience, would demand frequent business changes on such pages. Application rollouts for these changes mostly get coupled with other feature development and also places a risk of putting off customers with frequent downloads.

Solution

Initial thought towards solving this problem is to be able to dynamically load configurations mapped to each business requirement without frontend deployments. The underlying capabilities of a service providing these configurations would require additional:

• namespacing: after all, we wouldn’t want to fetch web product page layout on android homepage!
• versioning: not all versions of your application in the market would support each layout enhancement for a page!
• auditing: we wouldn’t want to eagerly fetch all these layouts from server, unless they are not updated!
• tagging: wouldn’t you require to just query documents based on certain attributes?

System Components

Primary components to build the complete interaction of end users with such a store involved:

• Consumer API: An aggregator layer that the clients could talk to understand when to ask for which layouts.
• Document Store: A web service to serve the configurations persisted.
• DataSore: The persistence layer for the various types of configurations dealt with.
• Console: A layer for receiving updates over the configurations.
• Cache: A guardrail towards the service and persistence layer against the throughput.

Entities

Entities involved in designing the system based on our requirements were broadly the following:

• Client: Representation of each team onboarded to the service, for instance mobile, ads, games, etc.
• DocumentType: Type specification for logical grouping of a set of documents, for example appConfigs
• Document: The actual documents with updates, versioning, values to reflect as configurations etc.
• Rule: Construct per documentType to define the rules for a document belonging to a namespace.
• UpdateHistory: History of a client’s update transitively derived by a document update.

Interaction

Interaction between these components and the entities involved could be illustrated as below:

Learnings

Document store was one of the projects to get me kick-started with the RESTful web service development. During the time I had spent on the project, the feature asks for which I was at the receiving end, and the production incidents that I had come across definitely made me learn:

1. Namespacing convention provided us an ease in scaling for other pages such as flyout, landing pages, banners etc. to board the service.

2. Cache invalidation strategies aligned as per the business requirements holds equal importance with the functional optimisation to sustain using minimal infra resources during high throughput circumstances.