When the Familiar Fixes Are Not Enough

Shopend’s database does not meet the performance targets under current load. Before scaling it, we should consider the ways we already know to reduce the work or add capacity.

Indexes

An index helps the database find the records an operation needs without searching through every record. Adding the right indexes could reduce the database’s work substantially.

Suppose we have checked the queries and their indexes. The database does less work per lookup, but the combined reads and writes still exceed its capacity. Adding more indexes is not a general solution either: the database has to update every index that a write touches.

Caching

Caching can serve some reads without the database. For example, if we can reuse a catalog response within the API’s freshness requirements, several shoppers can read that response without each request reading the same products again. That leaves the database more capacity for other work.

Not every read can use a cached response. A request may ask for data we have not cached, or the cached response may be too old to meet the freshness requirement. Those reads still reach the database.

A cache cannot serve a request to place an order either. Suppose a cached product says that two blue mugs are in stock. Another shopper may have bought them since that response was stored. We still need the conditional stock update from the previous chapter, and we still need to record the purchase. Assume that, even after caching the reads we can reuse, the remaining reads and writes together exceed the database’s capacity.

Vertical scaling

Vertical scaling gives the database more resources on one server. More memory, faster storage, or more processing capacity may let it complete more work in the same time. As with the API server, this is a useful option before changing the architecture.

Suppose we try a larger database server. It handles more reads and writes per second, but assume that the largest server we can use within our budget still cannot meet the performance targets at the expected load. We need a way to use the capacity of more than one database server.