Choosing a Caching Strategy for a Read-Heavy API

ReadFast API has a 50:1 read-to-write ratio and rising latency complaints. The manager must whiteboard a caching strategy and defend the tradeoffs in writing — no AI-generated architecture diagrams permitted in Phase 1.

# Aplly.xyz Case Study Submission

## Title
Choosing a Caching Strategy for a Read-Heavy API

## Type
Technology/IT

## Difficulty
Expert

## Estimated Time
75 minutes

## Overview
ReadFast API has a 50:1 read-to-write ratio and rising latency complaints. The manager must whiteboard a caching strategy and defend the tradeoffs in writing — no AI-generated architecture diagrams permitted in Phase 1.

## Case Details

Function Focus: System design reasoning, tradeoff analysis (latency, consistency, cost, complexity)

Scenario:
Product wants sub-100ms responses; current p95 latency is 450ms. The underlying data changes moderately — a few times per hour per record — and is not real-time-critical (a few minutes of staleness is acceptable to the business, but this must be explicitly confirmed, not assumed). Infra budget is capped.

Dataset Structure:
- Current architecture description (client → API → single relational DB, no cache layer)
- Traffic pattern: read/write ratio, requests/sec by hour
- Current latency percentiles (p50, p95, p99)
- Infra budget ceiling

Tasks:
1. Choose and justify a caching approach (write-through, write-behind, cache-aside, or TTL-based) by hand, before sketching anything
2. Diagram the chosen architecture (a hand-drawn sketch or photographed whiteboard is acceptable)
3. Explicitly explain the consistency tradeoff being accepted, and justify why it's acceptable for this specific use case
4. Estimate the expected latency improvement using reasoning (e.g., cache hit-rate assumptions, network hop reduction) — not a simulation tool

Expected Output:
Architecture sketch + written tradeoff justification + a reasoned latency-improvement estimate with stated assumptions.

Evaluation Criteria:
Correct tradeoff reasoning (rejecting "cache everything" as a non-answer), a realistic latency estimate with visible reasoning, and clear awareness of the consistency model being adopted.

## Data Sources

Traffic pattern:
| Hour Block | Reads/sec | Writes/sec |
|---|---|---|
| 00:00–06:00 | 800 | 15 |
| 06:00–12:00 | 3,200 | 70 |
| 12:00–18:00 | 4,500 | 90 |
| 18:00–24:00 | 2,100 | 45 |

Current latency: p50 = 180ms, p95 = 450ms, p99 = 900ms
Read/write ratio: ~50:1
Data change frequency: most records updated 2–4 times/hour; ~5% of records ("hot" items) updated far more frequently
Current DB: single-instance PostgreSQL, no read replicas
Budget ceiling: $1,500/month additional infra spend
Business constraint (confirmed with Product): up to 2 minutes of staleness is acceptable for 95% of endpoints; the remaining 5% (inventory-count endpoints) require near-real-time accuracy

## Solution Frameworks
Cache-aside vs. write-through vs. write-behind comparison, hot-key isolation strategy

## Solver Guidance & Tutorials
Link to: "Caching Patterns and Their Tradeoffs" tutorial

## What You'll Learn
- System design tradeoff reasoning under real constraints
- Defending architecture decisions without leaning on AI-generated diagrams
- Recognizing that not all data in a system needs the same consistency guarantee

## Tags
system design, caching, API performance, algorithmic thinking, technology/IT

## Registration Links
- Register as Solver
- Register as Evaluator