Shard City: Learn Database Sharding by Playing a Game

A visual strategy game that teaches sharding from zero: tables and indexes, replicas, shard keys, range vs hash vs directory, resharding, cross-shard…

Database sharding: common questions

What is the difference between replication and sharding?

Replication copies the same data to more machines, which scales reads. Sharding splits the rows across machines, which scales writes and storage. Shard City makes you hit the limit of replicas before you shard.

How do I choose a shard key?

Pick the key your main queries filter on, that spreads both data and traffic evenly, and that keeps data read together on one shard. Customer ID is common for order history; tenant ID for SaaS.

Related chapters

Keep learning

Previous: Games in System Design
Next: System Design Case Studies: Flash Sale, Chat, ChatGPT
All System design chapters

Overview

See it work The level opens on a healthy system with real rows and requests moving. Add pressure Traffic grows or a new requirement arrives. Watch it break One specific thing fails, visibly: a red meter, a lost row, a slow page. Click rows, requests, meters and the router to find out why. Change one thing Make a single architectural decision. Run exactly the same workload again, same seed, same timing. Before and after side by side: latency, errors, cost, skew. One short sentence about the trade-off you just saw. Little figures that send read requests (blue) and write requests (orange). The box that decides which database a request goes to. Its rules are editable. One or more servers. Every row is a visible card inside a table. CPU, storage, connections, latency and error rate per server. Every important event in order, so you can scrub back to the moment it broke. Run 10 requests, Add traffic, Crash server, Pause, Replay, Compare. Level 7 · Cache the hot reads Added. A cache is the next thing people try after replicas. Seeing that it fixes reads but not writes makes the Festival Sale boss land harder. Level 8 · Split the table, not the server Added. Partitioning inside one machine looks like sharding but adds no capacity. Learners mix the two up all the time. Level 42 · Hot and cold data Added. The final campaign asks for seven-year retention, so archiving old orders is taught before it is tested. Level 4 · The database has limits Sharpened. The player pauses and predicts which meter fails first, and the answer changes per seed, so it is observation, not memory. Level 3 · Find the right row Sharpened. The index also shows its cost: slower writes and more storage. Pass conditions Every level now has a number to hit on replay (p95, CPU, skew, lost rows) instead of “understand X”. Same-seed replay Each level fixes the random seed, so before and after are a fair comparison. Operational complexity On screen You do What breaks Pass when system design · games · shard city Shard City: Scale Without Breaking It You run a growing online store. Every customer, order and payment is a card you can see inside a database. As traffic grows you decide where data lives, route requests, split overloaded databases and recover from failures. You learn by changing the architecture, running traffic, watching it fail, and fixing it — not by answering a quiz.

The idea in one line

Sharding is never introduced as a definition. The player first feels one database run out, tries the simpler fixes (a bigger server, read replicas, a cache), watches them fail at the Festival Sale, and only then splits the rows. Every later topic is the same move, one step further.

How every level plays

When a decision is bad, the game shows the consequence — a lost row, a red customer, a bill — rather than the word “wrong”.

What is on the screen

Green · healthy Amber · warning, retrying, stale Red · failed, lost, rejected Blue · read Orange · write Final campaign

How the final levels are scored

There is no single correct architecture. A solution is scored on seven dimensions, and several different designs can score well.

What changed from the first idea

Read the theory alongside: Sharding · Consistent hashing · Sharding in an interview

More courses

Jobs, linked to lessons — Browse jobs where every requirement links to the chapter that teaches it. See how ready you are, how long the gap takes to close, and which listings look stale.
Match a job post to courses — Paste a job post. Each skill is matched to a track here and put in learning order, foundations first.
React from open source with patterns — Patterns extracted from Material UI, Radix, React Aria, React Hook Form, Redux Toolkit, TanStack, and Next.js — not slides about hooks.
Database in depth — How a query becomes work. Indexes, isolation, locks, and the plans that explain why a page is slow — not an ORM tour.
Build a real API with NestJS — One ticket-booking API, built in order: a plain Node server first, then NestJS modules, validation, a real database, and the features real clients lean on.
Microservices — Microservice patterns one diagram at a time: how to split a monolith, how services talk, and how data stays consistent without distributed transactions.
Kafka — A beginner-to-senior path through event logs, reliable delivery, production operations, and disaster recovery.
AI engineering for software engineers — Eight free reads, in order, for software engineers moving into AI: when to build an agent, how to build one, how to test it, and how the model works underneath.
Frontend system design — How a UI is sliced when it is a product, not a page: ownership of state, cache, routes, and what happens when the network lies.
TypeScript in depth — The type system as a design tool. Inference, narrowing, generics, and the errors that mean the model is wrong — not a catalog of utility types.
CSS in depth — See the box, then the page. Visual chapters from the box model through Flexbox surprises, Grid, selectors, and units, then backgrounds, shapes, and visual effects, each with a playground.
Accessibility — Foundations first (WCAG in plain words, semantic HTML, lists, alt text), then hands-on HTML labs, a full pass of WAI-ARIA 1.3, and a final fix-the-page challenge.
Docker — What an image is, why layers cache, and how containers find each other on a network.
Redis — Fifteen Redis patterns, one picture each: cache, session, lock, counter, rate limiter, queue, and when Redis is the wrong tool.
Kubernetes — Kubernetes from zero to operators: why it exists, Pods, Deployments and Services, then configuration, networking, storage, scheduling, scaling and security.