E-commerce platform architecture.
Four services with four completely different consistency requirements, which is the whole reason this is not one application.
The components
Every row below is read from the graph that produced the diagram above, so the two cannot disagree.
| Component | Tier | Why it is there |
|---|---|---|
| Storefront | Client | Supporting component |
| CDN | Edge | Supporting component |
| API gateway | Edge | Supporting component |
| Catalog | Application | Supporting component |
| Search | Application | Supporting component |
| Cart | Application | Session-scoped, tolerates loss |
| Orders | Application | The only service that writes order state |
| Inventory | Application | Reserves stock, releases on timeout |
| Payments | Application | Supporting component |
| Postgres | Data | Supporting component |
| Redis | Data | Supporting component |
| Event bus | Data | Supporting component |
| Payment provider | External | Supporting component |
Design decisions worth arguing about
A diagram shows what was chosen. It does not show what it cost, and that is usually the part that matters in a review or an interview.
The cart can lose data and the order cannot
These two look similar and could not be more different. A cart is a convenience: losing one annoys a user briefly, so it can live in a cache with a TTL and no durability guarantees. An order is a commitment with money attached, so it needs a durable transactional store and a single writer. Recognising that the two have different requirements is what lets the cart be cheap.
Reserve inventory, do not decrement it
Decrementing stock at checkout means an abandoned payment permanently removes an item from sale. Reserving with a timeout and releasing on expiry keeps availability honest at the cost of a background worker and a window where stock appears unavailable but is not. The alternative, decrementing only on payment success, oversells whenever two people check out simultaneously, which is worse for exactly the products you most want to sell.
Search is a projection and will lag
Serving search from the transactional database does not survive real catalog sizes, so search gets its own index built from events. That index is eventually consistent by construction: a price change is live in the catalog before it is live in search. Everyone accepts this until it applies to stock status, and a product shown as available in search but out of stock on the page is a support ticket rather than an architecture debate.
Only one service writes orders
It is tempting to let payments and shipping update order state directly, since they know things about it. Doing so means order state has several writers with no shared transaction, and reconstructing why an order is in a given state becomes archaeology. Routing every change through the order service costs an extra hop and keeps the state machine in one place where it can be reasoned about.
How it changes with scale
Traffic is dominated by browsing, which is cacheable and largely static, so the read path scales with the CDN rather than with your servers. Checkout volume is orders of magnitude smaller but touches the expensive consistent paths. This asymmetry is why splitting these services pays off: the parts that need to scale are not the parts that need to be correct.
Where it breaks first
A flash sale, which inverts every assumption at once. Traffic concentrates on a single product, so caches do not help because it is one key; inventory reservation becomes a contended row; and the payment provider becomes a rate limit you do not control. Systems that are comfortable at high steady volume routinely fall over on a small number of items at once.
Draw this yourself
Open the Diagram tab and describe the system. The agent emits a semantic graph rather than coordinates, so you can edit the components and the layout re-solves instead of drifting.
When the shape is right, Implement in code turns the canvas into a markdown specification, every component, every relationship and the notes, and starts a real turn in the Code tab with it.
Questions about this design
More templates
- URL Shortener System DesignThe canonical read-heavy system: roughly a hundred reads for every write, and a redirect that has to be fast enough that nobody notices it happened.
- Chat Application System DesignLong-lived connections change everything: the hard part is not storing messages, it is knowing which of your servers is holding the socket you need to write to.
- Payment System DesignThe only system on this list where being approximately right is indistinguishable from being wrong, and where the provider, not you, holds the truth.
- RAG Pipeline ArchitectureAlmost every RAG system that disappoints is failing at retrieval, not generation, and the architecture is what decides whether you can tell.