More Shops, the Same Database
In the previous chapter, we designed Shopend’s products, carts, and orders as documents. Products keep the attributes each merchant defines. Carts reference products so they can show current prices. Orders keep purchase snapshots, and placing an order uses a transaction to record the order, reduce stock, and mark the cart as ordered.
Now suppose more merchants join Shopend. Each merchant still has one shop, and most shops are small. But every shop’s products, carts, and orders are stored in the same database.
The load of all the shops
The shop API’s original load assumption was about 500 products and 200 orders a day. The previous chapter pointed out that those numbers describe one merchant. On Shopend, the database serves every merchant at once.
Suppose Shopend now has 10,000 shops. For this example, assume the following:
| Database work during a busy period | Assumed load |
|---|---|
| Reads | 10,000 per second |
| Writes | 1,000 per second |
These numbers count database operations, not API requests. One request can involve several reads and writes. Shoppers read catalogs, open carts, and look up past orders. They also change carts and place orders, which reduce stock, create an order, and update a cart.
Suppose load testing and profiling show that the database is the bottleneck. It cannot handle this increased workload fast enough to meet our performance targets.
More API instances, the same database
The chapter on scaling the API introduced running several API instances behind a load balancer. Suppose we already run Shopend that way:
graph TB
S[Storefronts] --> LB[Load Balancer]
LB --> A1[Shopend API Instance 1]
LB --> A2[Shopend API Instance 2]
A1 --> DB[(Shared Database)]
A2 --> DB
The load balancer spreads requests across the API instances, but both instances send their reads and writes to the same database. If we add another API instance, we can handle more requests in the API, but every read and write from that instance still goes to the same database, and the database is no faster than before.
We could refuse some requests through rate limiting or load shedding, and that would reduce the work, but the shoppers we turned away could not complete their purchases.