The Course With 300 Seats and 24,000 Registration Attempts
The Course With 300 Seats and 24,000 Registration Attempts
This situation follows the lesson Sharding, Hot Keys & Rebalancing. Solve it on paper before you open a hint. The Teacher Gold Answer holds the worked solution, the other valid approaches and what a strong answer at each level demonstrates.
The scenario
Northfield University has 50,000 students and 2,000 courses. Students register for courses online, and registration for the autumn term opens at 08:00:00. Every course has a fixed number of seats. A registration takes a seat only if one is free, and a course never has more registered students than seats.
The registration store is a sharded key-value store of the kind the lesson Sharding, Hot Keys & Rebalancing describes: 16,384 slots, slot = CRC16(tag) mod 16,384 with hash tags, eight shards S0 to S7 that own 2,048 slots each (S0 owns slots 0 to 2,047), and six stateless routers, two in each Availability Zone, that cache the directory. Each router has a micro-cache (one entry per key, fresh for 1 s, usable up to 3 s with one refresh in the background, single-flight on a miss) and a per-key limiter. A shard takes 1,000 writes a second and 3,000 reads a second (labelled, as in that lesson); above that it throttles every key it holds.
Two keys matter:
seats:{CS101}holds the number of free seats in course CS101. It is in slot 47, on S0. A registration attempt is one conditional write to this key: "subtract 1 if the value is at least 1" (seats >= 1). The shard checks the condition and applies the write, or refuses it. The response carries the value after the write, or the value 0 on a refusal.reg:{s123}holds student s123's registrations, keyed by the student. The write to it comes after the seat is taken and is not part of this challenge.
Every student can open a course's page, which shows "seats left" and polls the store once a second.
| Setting | This challenge | At real scale |
|---|---|---|
| Seats in CS101 | 300 | A country-wide platform: 2,000,000 students, 60,000 courses |
| Attempts | 24,000 students have CS101 in their plan, and their browsers send the registration attempt as soon as registration opens: 24,000 attempts in the first 10 s, spread evenly, so 24,000 ÷ 10 = 2,400 a second, one every 2.5 ms per router (an assumption: the attempts arrive at a steady rate) | 200,000 attempts in 10 s on the most wanted course: 20,000 a second |
| Reads | The same 24,000 students keep CS101's page open, so it polls 24,000 times a second, spread evenly over the routers | 200,000 a second |
| S0's other traffic | The other courses in S0's slots add 200 writes a second and 400 reads a second at 08:00 (an assumption) | Same share |
| Shard ceiling (labelled) | 1,000 writes a second and 3,000 reads a second | DynamoDB: 1,000 write units and 3,000 read units a second per partition |
| Micro-cache | Fresh for 1 s; usable up to 3 s with one refresh in the background; single-flight on a miss; a decrement's response is stored as a fresh entry | Same |
| Per-key limiter | A budget per key, set by you, enforced by the routers: an attempt over the budget gets 429 Too Many Requests with Retry-After of 1 s. Assume the routers share the budget evenly and admit attempts at a steady rate | Leased blocks per router |
| Round trip | A router's request reaches the shard 1 ms after it is sent, and the response is back 1 ms after that (an assumption) | Same |
| The team's proposal | "Treat seats:{CS101} like a like counter: each router subtracts locally and flushes a summed decrement every 500 ms" |
Synthesizing vector architecture diagram...
seats:{CS101} with 300 seats and checks the condition seats >= 1 on every attempt. The dashed arrows are the second write of a registration, the student's own reg:{student} key, which lands on whichever shard owns that student's slot; it is not part of this challenge. S1 to S7 are drawn to show that they are not involved: the problem is one key, not the cluster.What happens. At 08:00:00 the attempts and the page reads start. The team must decide the read path and the write path for seats:{CS101} before that moment, and the proposal the team has made is to reuse the like counter's design.
Your task
Design the read path and the write path for seats:{CS101} for the first 10 seconds after 08:00:00. A complete answer gives: how many reads and how many writes reach S0 for this key with your design, with the arithmetic; the hot-key fix you reject and the number of seats it would give away above 300; and the one weakness your design still has.
Hints
Open a hint only when you are stuck. Each hint gives a little more.
The Course With 300 Seats and 24,000 Registration Attempts
This situation follows the lesson Sharding, Hot Keys & Rebalancing. Solve it on paper before you open a hint. The Teacher Gold Answer holds the worked solution, the other valid approaches and what a strong answer at each level demonstrates.
The scenario
Northfield University has 50,000 students and 2,000 courses. Students register for courses online, and registration for the autumn term opens at 08:00:00. Every course has a fixed number of seats. A registration takes a seat only if one is free, and a course never has more registered students than seats.
The registration store is a sharded key-value store of the kind the lesson Sharding, Hot Keys & Rebalancing describes: 16,384 slots, slot = CRC16(tag) mod 16,384 with hash tags, eight shards S0 to S7 that own 2,048 slots each (S0 owns slots 0 to 2,047), and six stateless routers, two in each Availability Zone, that cache the directory. Each router has a micro-cache (one entry per key, fresh for 1 s, usable up to 3 s with one refresh in the background, single-flight on a miss) and a per-key limiter. A shard takes 1,000 writes a second and 3,000 reads a second (labelled, as in that lesson); above that it throttles every key it holds.
Two keys matter:
seats:{CS101}holds the number of free seats in course CS101. It is in slot 47, on S0. A registration attempt is one conditional write to this key: "subtract 1 if the value is at least 1" (seats >= 1). The shard checks the condition and applies the write, or refuses it. The response carries the value after the write, or the value 0 on a refusal.reg:{s123}holds student s123's registrations, keyed by the student. The write to it comes after the seat is taken and is not part of this challenge.
Every student can open a course's page, which shows "seats left" and polls the store once a second.
| Setting | This challenge | At real scale |
|---|---|---|
| Seats in CS101 | 300 | A country-wide platform: 2,000,000 students, 60,000 courses |
| Attempts | 24,000 students have CS101 in their plan, and their browsers send the registration attempt as soon as registration opens: 24,000 attempts in the first 10 s, spread evenly, so 24,000 ÷ 10 = 2,400 a second, one every 2.5 ms per router (an assumption: the attempts arrive at a steady rate) | 200,000 attempts in 10 s on the most wanted course: 20,000 a second |
| Reads | The same 24,000 students keep CS101's page open, so it polls 24,000 times a second, spread evenly over the routers | 200,000 a second |
| S0's other traffic | The other courses in S0's slots add 200 writes a second and 400 reads a second at 08:00 (an assumption) | Same share |
| Shard ceiling (labelled) | 1,000 writes a second and 3,000 reads a second | DynamoDB: 1,000 write units and 3,000 read units a second per partition |
| Micro-cache | Fresh for 1 s; usable up to 3 s with one refresh in the background; single-flight on a miss; a decrement's response is stored as a fresh entry | Same |
| Per-key limiter | A budget per key, set by you, enforced by the routers: an attempt over the budget gets 429 Too Many Requests with Retry-After of 1 s. Assume the routers share the budget evenly and admit attempts at a steady rate | Leased blocks per router |
| Round trip | A router's request reaches the shard 1 ms after it is sent, and the response is back 1 ms after that (an assumption) | Same |
| The team's proposal | "Treat seats:{CS101} like a like counter: each router subtracts locally and flushes a summed decrement every 500 ms" |
Synthesizing vector architecture diagram...
seats:{CS101} with 300 seats and checks the condition seats >= 1 on every attempt. The dashed arrows are the second write of a registration, the student's own reg:{student} key, which lands on whichever shard owns that student's slot; it is not part of this challenge. S1 to S7 are drawn to show that they are not involved: the problem is one key, not the cluster.What happens. At 08:00:00 the attempts and the page reads start. The team must decide the read path and the write path for seats:{CS101} before that moment, and the proposal the team has made is to reuse the like counter's design.
Your task
Design the read path and the write path for seats:{CS101} for the first 10 seconds after 08:00:00. A complete answer gives: how many reads and how many writes reach S0 for this key with your design, with the arithmetic; the hot-key fix you reject and the number of seats it would give away above 300; and the one weakness your design still has.
Hints
Open a hint only when you are stuck. Each hint gives a little more.
Provide 1–2 precise sentences for each architectural dimension. Each box guides you on what staff-level interviewers evaluate.
Define SLA targets, hard consistency constraints, and conditions the system must never violate.
Quantify throughput (QPS/RPS), read:write ratios, and peak burst multipliers.
Step-by-step path: client ingress → API gateway → queues → background workers → persistence.
Database engine, table schema, partition keys (PK/SK), and durability strategy.
What resource hits saturation first under 10x traffic? (CPU, disk IOPS, connection pools, network).
Worker crashes, network partitions, split-brain, poison pill DLQ, retries, and idempotency.
What did you sacrifice in exchange and why? (e.g. eventual consistency vs latency, cost vs redundancy).