All cardsSix system design patterns, in plain English
Six system design patterns, in plain English
Eric Tech packs the six problems every growing app runs into, and the fixes for each, into one Short. In one line: keep copies close for reads, hand slow work to the background, and plan for every piece to fail. This page explains each one so you can ask your coding agent for it by name.
Jump to the map, which fix when, or the prompts.
Original source
The video
A YouTube Short, 1:26, posted Oct 9, 2026. The top half is an animated diagram, the bottom half is Eric talking. Shorts have no chapters, so these are ours. Each timestamp opens the video at that moment.
- 0:00 Six problems every app runs into
- 0:13 1 · Lots of people reading the same thing
- 0:20 2 · Tons of data coming in at once
- 0:28 3 · Updates the second they happen
- 0:36 4 · A job that takes minutes
- 0:45 5 · Reads and writes that want different setups
- 0:55 6 · Everything fails: reliability
- 1:14 His Skool plug (left out)
Made by Eric Tech (@EricWTech), who makes longer videos on Claude Code and AI engineering.
Eight signals
Seven from the video, one from us (marked). Each links to where this page explains it.
- 010:00
Six problems, one fix each
Any app that grows hits the same six walls, whatever language it's in. The fixes are known. The hard part is knowing which one to reach for.
How - 020:13
Many readers: keep a copy close
When lots of people load the same thing, don't ask the database every time. Keep a copy (cache), add copies of the database (replicas), or help it find things faster (index).
How - 030:20
A flood of saves: group, split, or save later
When data pours in, save it in groups (batching), spread it over several databases (sharding), or say "got it" now and save it in the background (async writes).
How - 040:28
Live updates: keep the line open
For chat and live status, the server needs to tell the user the moment something changes. WebSockets, server-sent events and long polling all keep a line open.
How - 050:36
Slow jobs: hand them off
A report that takes minutes shouldn't freeze the button. Drop it in a queue, answer the user right away, and let workers do it in the background.
How - 060:45
Reads and writes: split them
When saving and reading need very different setups, CQRS gives each its own model. One is built for saving, one for reading.
How - 070:55
Everything fails. Plan for it
Retries that wait longer each time, idempotency so a repeat doesn't double-charge, circuit breakers that stop calling a dead service, and self-healing. He calls this the part that separates junior from senior.
How - 08FakeNerd
The name is the handle
Your coding agent already knows all seventeen techniques. What it needs from you is the name and the place. "Add an idempotency key to checkout" gets a real fix. "Make payments safer" gets a guess.
How
Words on this page
Fifteen everyday words first. The seventeen techniques themselves are explained in Everything he names.
- System design
- Deciding how the parts of an app fit together (screens, servers, databases, background jobs) so it stays fast and keeps working as more people use it.
- Pattern
- A known fix for a problem that keeps coming up. It has a name so people (and agents) can talk about it in one word.
- Read and write
- Read means loading data (open a product page). Write means saving data (place an order).
- Database
- Where the app keeps its data for good: users, orders, messages.
- Server
- The computer running your app's code. Your phone or browser asks it for things.
- Endpoint, GET and POST
- An address on the server that does one thing. GET /product/42 asks for product 42. POST /orders sends a new order. These were on screen in the video.
- 202 Accepted
- A server reply that means "got it, I'll finish this in the background". Shown on screen for async writes.
- API
- The way one program talks to another. A payments API is how your app asks a payment company to charge a card.
- Service
- One part of a bigger system that runs on its own, like payments-api or orders-service in the video.
- Primary
- The main copy of the database, the one that takes the saves. Replicas copy from it.
- Stale data
- A copy that's a little behind the real thing. The price for most speed tricks: a cache or replica can show yesterday's number for a moment.
- Latency
- How long something takes to answer. Lower is faster.
- Job
- A piece of work done in the background, like generate-report.job in the video.
- Model (in CQRS)
- Here it means how the data is shaped and stored, not an AI model. A write model is shaped for saving, a read model for reading.
- Happy path
- The way things go when nothing breaks. Agents write this first. Reliability is everything else.
What it is, and where you've already met it
A pattern is a known fix with a name. You use apps built on all six every day. The examples are ours.
In one breath
An app starts as one server and one database. As more people use it, six things start to hurt. Each has a short list of well-known fixes. You don't need all of them. You need to spot which one hurts and know its name.
Eric says it goes for Python, Java and JavaScript alike. It goes for any language: these are about how the pieces fit, not the code inside them. 0:00
Basicpattern 01
A recipe blog goes viral
Same page, ten thousand visitors. A cache answers almost all of them and the site stays up.
Basicpattern 03
"Ana is typing…"
The dots appear the moment she types. An open line pushes it to you without a refresh.
Basicpattern 04
"We'll email your export"
The download takes five minutes, so it goes in a queue. You close the tab and get an email later.
Advancedpattern 02
Concert tickets go on sale
A hundred thousand orders in one minute. Replies come back 202 at once, saves are batched, and the orders are split across databases by event.
Advancedpattern 05
The sales dashboard
The owner wants totals by day, by product, by city. A separate read model keeps those ready, so reporting never slows down checkout.
Advancedpattern 06
The payment that didn't double
The network drops mid-payment. The app retries with the same key, the payment company sees it's the same order, and the card is charged once.
Everything he names
Seventeen techniques in 86 seconds, grouped by the problem they fix. The plain line is ours. The tools column is common examples we added; the video names no products. Effort is our guess for a small app.
01 · Fast reads · many people, same data 0:13
- CachingKeep a ready copy of common answers.Redis, Valkey, a CDN, Cloudflare KVeffort low
- Read replicasRead-only copies of the database.Postgres or MySQL replicas, most hosted databaseseffort medium
- Database indexA shortcut so lookups don't scan everything.Built into every databaseeffort low
02 · Heavy writes · tons of data coming in 0:20
- BatchingSave many rows in one trip.Your database's bulk inserteffort low
- ShardingSplit the data across several databases.Vitess, Citus, built-in in some hosted databaseseffort high
- Async writesReply now, save in the background.A queue plus a workereffort medium
03 · Live updates · updates the second they happen 0:28
- WebSocketsTwo-way line that stays open.Socket.IO, Pusher, Ably, Durable Objectseffort medium
- Server-sent eventsServer pushes updates down one way.Built into browsers (EventSource)effort low
- Long pollingAsk, and the server waits until there's news.Plain HTTP, no extraseffort low
04 · Slow jobs · a task that takes minutes 0:36
- Message queueA to-do list for background work.SQS, RabbitMQ, Kafka, Cloudflare Queueseffort medium
- Worker poolBackground programs that take jobs off the queue.Sidekiq, Celery, BullMQeffort medium
- Workflow engineMany-step jobs that resume where they failed.Temporal, Inngest, Trigger.deveffort medium
05 · Split reads and writes · saving and reading want different setups 0:45
- CQRSSeparate models for saving and reading.A pattern, not a producteffort high
06 · Reliability · every piece fails at some point 0:55
- Retries with backoffTry again, waiting longer each time.Most HTTP and SDK clients have an optioneffort low
- IdempotencyA repeat has no extra effect.An Idempotency-Key header; Stripe supports iteffort low
- Circuit breakerStop calling a service that keeps failing.resilience4j, opossum, a service mesheffort medium
- Self-healingCrashed parts restart themselves.Health checks in Kubernetes, Fly, Railway, Rendereffort medium
The only other things he names are the three languages, Python, Java and JavaScript, to say the problems don't care which one you use.
One app, six patterns
Each pattern placed where it lives in a normal app. Click a box to read it, or press Start and follow one order through all six. The dashed boxes are parts of the app, not patterns.
One app · where each pattern lives · the darker box wraps all the others
Follow one order through the six
Seven beats in a sneaker shop on launch day: one customer, Ana, from opening the page to the payment company going down. The story is ours. Watch which box lights up at each step.
Pattern 1 of 6
Watch at 0:13Fast reads
When: Lots of people are loading the same data, so the database gets asked the same question over and over.
- CachingKeep a ready copy of the answer in fast memory. Most visitors get the copy.
- Read replicasExtra copies of the database that only answer reads, so the main one can focus on saves.
- Database indexLike the index in a book: the database jumps straight to the row instead of reading every one.
On screen in the video
Five users ask GET /product/42. A cache answers HIT five times. Below it, a primary and two replicas each hold id 42.
Where you've seen it · ours
A recipe goes viral. Ten thousand people open the same page in an hour. A cache serves almost all of them.
Watch out
Copies go stale. Decide how old is OK (a product photo: hours; a stock count: seconds) and when the cache gets cleared.
Ask your agent · ours
Find the slowest page that many people load. Add an index if the query is slow, then a cache with a sensible expiry.
Eric shows each pattern on its own. Putting them in one app, and the shop story, are ours. The screen notes in each box are read from the video.
Which fix when
Pick what your app is doing. You get the cheapest first move and the next one. Ours, built on his six.
My app…
Pattern 01 · Fast reads
Do this first
Add a database index for the query behind it. Free and often enough.
If that's not enough
Cache the result. If the database is still busy, add a read replica.
Watch out: Copies go stale. Decide how old is OK (a product photo: hours; a stock count: seconds) and when the cache gets cleared.
Reliability, up close
Eric's claim: this last one is what separates junior engineers from senior ones, and self-healing is the game changer. Here are his four, one picture each. 0:55
1 · Retries that wait longer each time
1:01- Try 1now
- Try 2wait 1 s
- Try 3wait 2 s
- Try 4wait 4 s
- Try 5wait 8 s
Each wait doubles, so a struggling service gets room to recover instead of a flood. Add a little random jitter so a thousand users don't all retry at the same second. The numbers are ours, as an example.
2 · Idempotency: twice counts once
1:04Without a key
try 1 · charged, reply lost try 2 · charged again = two charges
With a key
try 1 · key a91f · charged try 2 · key a91f · already done = one charge
The first try went through, but the reply got lost, so the app tried again. The key is a made-up ID for this one payment. The retry carries the same key, so the payment company knows it's a repeat. The video shows Idempotency-Key: a91f on screen.
3 · Circuit breaker: stop calling what's down
1:06- ClosedCalls go throughNormal. The breaker counts failures. This is the state shown in the video.
- OpenCalls stopToo many failures. For a set time, every call fails fast with a friendly message instead of hanging.
- Half-openOne test callAfter the wait, let one call through. Works: close the breaker. Fails: open it again.
Named after the switch in your fuse box. The video shows it closed between checkout and a payments-api marked down. The three states are the standard version; only the first is on screen.
4 · Self-healing: it fixes itself
1:09- 1A health check pings each service every few seconds.
- 2payments-api stops answering.
- 3The platform restarts it, or starts a fresh copy.
- 4The health check passes. Traffic flows again.
On screen: payments-api ↻ restarting…. Most hosting platforms do this for you once you give them a health check. That's why it's the cheapest big win of the four.
Ask your agent by name
The video has no prompts. These three are FakeNerd starters, each with a fill-in version. Start with the audit: it changes nothing.
FakeNerd starter · audit for the six
Look through this codebase for the six common system design problems. Don't change any code yet. For each one, tell me where it shows up (file and function), how bad it is today, and the smallest fix: 1. Fast reads: data many users load again and again (cache, read replica, index) 2. Heavy writes: saves in a loop or under bursts (batching, async writes, sharding) 3. Live updates: screens people refresh to see news (SSE, WebSockets, long polling) 4. Slow jobs: anything a user waits more than 3 seconds for (queue + worker) 5. Reads vs writes: reports that slow down saving (read replica first, CQRS later) 6. Reliability: every call to an outside service (timeout, retry with backoff, idempotency key, circuit breaker) Answer as a table: problem, where, how bad (none / low / high), smallest fix. Mark anything you're unsure about. Then wait for me to pick one.
Fill-in · audit
Look through [the folder or feature] for the six common system design problems. Don't change any code yet. Our app: [what it does], about [number] users, built with [language / framework]. The part that worries me most: [the slow page, the double charge, the spinner]. Table: problem, where, how bad, smallest fix. Then wait for me to pick one.
FakeNerd starter · one fix, done right
Add retries with backoff and an idempotency key to the payment call in checkout. - Time out after 10 seconds. - Retry up to 3 times, waiting 1 s, 2 s, then 4 s, plus a little random jitter. - Send the same Idempotency-Key on every retry of the same order. - If all retries fail, show the user "Payments are down, try again in a minute" and log it. - Write a test that fakes two timeouts and proves the card is charged once.
Fill-in · one fix
Add [pattern: a cache / a background job / retries with backoff / an idempotency key / SSE] to [the exact place: file, function, endpoint or screen]. - Why: [the symptom you see]. - Limits: [how stale is OK / how long to wait / how many retries]. - When it fails, the user sees: [message]. - Prove it with: [a test or a before/after timing].
FakeNerd starter · reliability check
List every place this app calls something outside itself: payment, email, AI model, maps, another of our services. For each one, answer: - Is there a timeout? How long? - Does it retry, and does each retry wait longer? - If it charges, sends or creates something, is there an idempotency key? - If it's down for an hour, what does the user see? Table first. No code changes until I say which to fix.
The reliability check is the senior part as a prompt. It has no fill-in because it works on any app as is. Run it after the audit, or alone if your app takes payments.
The three prompts are on the web version of this page: fakenerd.ai/system-design-patterns#prompts
Try it, smallest version first
- 01
Open your project with a coding agent
Claude Code, Codex, Cursor, or in the browser with Cloudroom or bb. Any app you've built works, even a small one.
- 02
Run the audit, change nothing
Paste the audit prompt. You get a table of where the six show up. Most small apps score "none" on four of them. That's normal.
The audit prompt - 03
Fix the slowest page first
Ask for an index, then a cache. Time the page before and after. This is pattern 1 and it's usually the biggest win for the least work.
- 04
Wrap one outside call
Pick the call that matters most, usually payments or email. Add a timeout, retries with backoff and an idempotency key.
How the four work - 05
Move one slow button to the background
If anything makes the user wait more than a few seconds, make it a background job and tell them when it's done.
- 06
Leave sharding and CQRS for later
You'll know you need them: one database maxed out, or reports fighting with checkout. Until then they add more work than they save.
Next to the others
Other plain-English fundamentals on this site, and how this one fits.
FakeNerd's take
A name is a handle for your agent
The agent knows every one of these. What it can't guess is where your app hurts. Seventeen names turn "make it faster" into "cache GET /product/:id for five minutes", and that one gets done right.
Don't build Netflix on day one
A small app needs an index, a cache, one background queue and careful outside calls. Sharding and CQRS are real, and they're for when you've measured the pain. Added early, they're pure cost.
He's right about reliability
Agents write the happy path unless you ask. The double charge, the hung checkout and the silent failed job all live in the parts nobody asked for. Ask for them by name.
86 seconds is the map, not the manual
The Short gives you the names and the problem each one solves. That's its job, and it does it well. This page adds the when, the trade-off and the words to type.
Attribution
- “6 System Design Patterns Every Dev Needs” by Eric Tech (posted Oct 9, 2026). The six problems, the seventeen techniques, the junior-to-senior line and the self-healing line are his, in our words. Screen notes (GET /product/42, 202 Accepted, generate-report.job, Idempotency-Key: a91f and the rest) are read from the video. Caption slips fixed: “rights” is writes, “item potency” is idempotency.
- The end of the Short promotes his paid Skool community. It isn't part of the teaching and is left out. The diagram animations appear to be built with a coding agent (a Claude Code session is on screen at 0:11). He doesn't say so.
- The glossary wording, every example, the one-app map, the shop walkthrough, the picker, the tools and effort columns, the backoff numbers, the three breaker states, the prompts, the setup order and the takes are FakeNerd's. Not sponsored by anyone on this page.