I used to memorize system designs. Uber = location service + Redis Geo + WebSocket. WhatsApp = message queue + delivery receipts + fan-out. Netflix = CDN + encoding pipeline + recommendation engine.

Then I walked into an interview and got: "Design a real-time collaborative spreadsheet."

I hadn't memorized that one. I froze for 10 seconds. Then I realized — I didn't need to memorize it. Every system design breaks down into the same 4 decisions, asked in order:

Decision 1: What's the write path? (first 5 min)

Every system either writes synchronously or asynchronously. Ask yourself: "Does the user need confirmation that the write succeeded?"

• Payment → synchronous (user needs "payment confirmed")
• Analytics event → asynchronous (fire and forget, queue it)
• Spreadsheet cell edit → synchronous to the user, async fan-out to collaborators

This one decision determines 60% of your architecture. Sync writes = you need strong consistency somewhere. Async writes = you need a durable queue (Kafka/SQS/Kinesis).

Decision 2: What's the read pattern? (next 5 min)

Three options:

1. Point read — fetch one thing by ID (user profile, order details) → KV store
2. Range/list read — fetch N sorted things (timeline, search results) → sorted index or pre-materialized view
3. Aggregation read — compute something over many rows (analytics, leaderboard) → pre-computed rollup or OLAP store

The spreadsheet? It's a point read (load sheet by ID) + streaming updates (subscribe to cell changes). That tells me I need a DB for persistence + a pub/sub layer for real-time sync.

Decision 3: Where does the hot data live? (next 5 min)

Data has temperature:

• Hot (accessed every second): Redis, in-memory, local cache
• Warm (accessed every minute): DynamoDB/Cassandra, read replicas
• Cold (accessed rarely): S3, data warehouse, archive tier

For the spreadsheet: the currently-open sheet is hot (every keystroke hits it). Closed sheets are warm. Sheets not opened in 30 days are cold.

This maps directly to: Redis for active sessions → Postgres/DynamoDB for sheet storage → S3 for version history and deleted sheets.

Decision 4: What fails, and what happens when it does? (last 5 min of design)

Pick the most likely failure for your system and have an answer:

• Network partition → which side accepts writes? (CAP theorem, not a theoretical question)
• Node crash → where's the WAL? How do you recover?
• Thundering herd → what's the rate limit? Where's the circuit breaker?
• Duplicate delivery → where's the idempotency key?

For the spreadsheet: two users edit the same cell at the same time. That's a conflict. You need a resolution strategy — last-writer-wins with vector clocks (like Google Docs uses CRDTs, Figma uses a central server as arbiter).

My 35-minute structure:

[0-3 min]   Requirements (3 functional, 3 non-functional)
[3-8 min]   Write path decision + API design
[8-13 min]  Read pattern decision + data model
[13-20 min] Hot/warm/cold tiers + high-level diagram
[20-30 min] Deep dives (2-3, driven by NFRs)
[30-35 min] Failure modes + tradeoffs discussed

The beauty: I never memorized "Design a Collaborative Spreadsheet." I derived it from first principles in 20 minutes. The interviewer said "that's exactly how we built it internally."

This framework works because it mirrors how real systems are actually designed. Nobody at Google sat down and said "let's memorize the Google Docs architecture." They asked: what's the write path? What's the read pattern? Where does hot data live? What breaks?

I practice this framework against 33 different designs on SystemCraft (Google it). By the 6th one, the 4 decisions become muscle memory. You stop thinking about which cache to use and start reasoning about why.