Chiper Microservices Architecture Redesign

A distributor that supplies thousands of small shops usually starts on one application that takes orders, holds the catalogue, records sales and reports on them. As the network grows, one heavy report or one busy week of orders slows everything down, and no part can change or scale without redeploying the whole. Moving such a platform to services is a series of choices rather than a rewrite: where to cut, which data each part owns, how parts that share data stay consistent, and how to prove each choice against a measured requirement. This project makes those choices for a supplier of corner stores in Latin America, one quality requirement per sprint.

The platform is cut by business capability into a core for orders and the owners' pages, a catalogue service, a store service for sales and a reports service, built in two technologies. The catalogue publishes every change to an event broker, and the store service keeps its own copy of the catalogue from those events, so it does not have to call the catalogue to work. Suggestions for each zone are ranked by a weekly job over the last seven days of sales and served as a stored report, so an owner's request reads one document instead of adding up millions of sale lines. Login and roles sit with an external identity provider, and each requirement was checked with a load test or a code scan against a seeded dataset of about seven million rows.

• Learning

  Each service owns its data

  The store service has its own database and learns about products only from events, so it can be deployed, scaled or restored without asking anyone. The core and the catalogue still wrote to one shared table, and that is exactly the coupling that makes two services move as one. A service is independent in production only when no other service reads or writes its tables.

• Learning

  Events instead of calls between services

  Publishing a change once and letting any number of services subscribe removes the chain of synchronous calls, so a slow or stopped catalogue does not stop a sale. The price is that each copy is eventually right, not instantly right, and the delivery guarantee decides how far it can drift: at most once is cheap and can lose a change, while a copy that must stay correct needs at least once delivery and updates that are safe to apply twice. Choosing that guarantee on purpose is what makes replicated data trustworthy.

• Learning

  Quality requirements as measured targets

  Every sprint turned a quality into a target and a test: how quickly an owner sees suggestions, how many order history requests the core serves each second. Ranking once a week instead of on every request is a choice that only makes sense against such a target, since it trades fresh rankings for an answer read from one stored document. Architecture decisions hold up in production only when each one is tied to a target that a test can pass or fail.