Discussing tradeoffs clearly

01A tradeoff is a consequence, not a slogan

A shop receives 10,000 product-page reads and 20 description edits each second. Tests show that its database meets the response-time and error targets at up to 2,000 description reads per second. Reading the database for every page would exceed that limit.

Keeping descriptions in a cache means saving an extra copy that many page requests can reuse. The copy saves database reads, but it may not include the latest edit. This is a tradeoff: we accept a specific cost to obtain a useful benefit.

First separate the shop's promises:

1. Browsing: a product description may be up to 30 seconds old.
2. Buying: the purchase service must verify the agreed price and the buyer's current permission before accepting an order.
3. Capacity: database traffic must remain within its tested safe rate, including during failures.

The first promise permits some older display data. It does not permit checkout to charge an old price. A requirement that must always hold is a hard constraint; a preference such as lower cost helps choose among designs that already satisfy those constraints.

02Use a small decision record

Compare complete request paths, rather than giving technologies scores in isolation.

Write a short decision record:

1. State the problem: description reads exceed database capacity.
2. State the assumption: enough visitors read the same products for caching to help. A proposed 90% hit rate is a hypothesis, not a property of installing a cache.
3. Choose a candidate and calculate its effect: estimate how many page requests still need the database.
4. Explain the cost: describe how edits reach copies and what happens when the cache fails.
5. Name a reason to revisit: measured database reads above 2,000/s or descriptions older than 30 seconds invalidate the choice.

Exclude a design that breaks purchase correctness before comparing its price or average response time.

03Worked decision: product descriptions

Follow one product page and one edit:

1. A browser requests product 42. The application looks for that product's cached description. It uses the copy only if fewer than 30 seconds have passed since the database verified that description. A delayed cache fill must keep that original verification time; storing it later must not restart the 30 seconds.
2. If no usable copy exists, the application reads the database. It saves a replaceable copy for later visitors. At 90% hits, 10% of 10,000 requests reach the database: 1,000 reads/s, plus refresh work. That fits the assumed 2,000/s capacity.
3. An editor saves a new description. Save it in the database first. Then update the cached copy or remove it so the next reader reloads it. Removing a cached value is called invalidation.
4. Account for a slow reader. A reader might load an old description before the edit and put it in the cache afterward. Version checks or another coordinated update rule must handle this race. An expiry timer alone does not make every edit immediately visible.
5. The customer buys the item. The purchase service checks the price and permission using the records that decide the purchase. A description-cache hit is not permission to buy.
6. The cache fails. Up to 10,000 reads/s could now reach the database. Keep description reads, including refreshes, within the tested 2,000/s limit, and reserve capacity for purchase checks. Reuse descriptions only within their 30-second limit; reject browsing requests that would exceed the remaining capacity.

Now lower the hit-rate assumption to 75%. The database receives 10,000 × 25% = 2,500 reads/s, already above its safe rate. The calculation changes the decision even though the architecture drawing still contains the same boxes.

04Explain uncertainty and change

Explain the decision with the same concrete promises used to make it:

• Why cache? Repeated description reads can share a copy, reducing database work while the product permits a 30-second delay.
• What stays separate? The purchase service still verifies current purchase details. A faster page cannot justify an incorrect order.
• Who maintains copies? Name the application or worker that updates them, records failures and retries missing updates.
• What is measured? Track database reads, description age, response time and errors separately. A high hit rate with old data is not success.
• When should the design change? Immediate edit visibility requires a different read/update rule. A fall to 100 reads/s may make direct database reads simpler.

A concise interview explanation is: “Descriptions may be 30 seconds old, so repeated reads can use a cache. Checkout verifies the purchase independently. I will test hit rate and cache failure, and revisit the choice if database reads or description age exceed their limits.”