CampusClip walk

1The problem: long URL to short code

CampusClip has two jobs and only two. Write: a teacher pastes a long URL and gets back a short code. Read: a student opens that code and is redirected. Everything we have already named — one box versus many, load versus capacity, latency versus throughput, a cache, a queue — is in service of those two jobs.

We will not invent a worldwide QPS. We keep the classroom givens: 800 students, a 9:00 burst we already measured, host capacity 20 redirects/s, reply 250 bytes, mean latency 0.2 s when the host is keeping up. The walk is how those pieces sit on the two paths.

Figure. Two paths, one store. Write inserts a code. Read looks it up and sends the student to the long URL.

The two jobs

1. WritePaste long URL → store a code → return clip.campus/CODE.
2. ReadOpen CODE → look up the long URL → 302 redirect.
3. ReuseLoad, cache, queue, and scale choices attach to one of those two paths.

2Write path: mint a code

On paste, CampusClip creates a short code, writes code → long URL to the store, and returns the short link. That insert is synchronous: the teacher is waiting on the code. After the response, CampusClip may enqueue "email the link" — that is the queue we already allowed.

The code must be unique. A simple classroom scheme: draw six characters from a 62-symbol alphabet (a–z, A–Z, 0–9). That is 62^6 possible codes — we will compute that on the capacity sketch, not here. If the insert hits a duplicate, try another code. Do not return a code the store has not accepted.

Figure. Paste is synchronous into the store. The email queue is dashed — it starts after the teacher already has the code.

How a paste becomes a link

1. MintPick a unused short code.
2. InsertWrite code → long URL in the store. Wait for success.
3. ReplyReturn clip.campus/CODE. Then, optionally, enqueue the email.

3Read path: look up and redirect

On open, the student hits the balancer, a CampusClip host asks the shared cache for the code, and on a miss loads the store, fills the cache, and replies 302. That whole path is synchronous. A click increment may be enqueued after the 302 — the student is not waiting on the counter.

This is why the cache sits beside the app, not only in one process: the balancer may send the next open of a3k9 to a different host. It is also why the mapping store leans CP: two different long URLs for one code is a wrong redirect, not a delayed counter.

Figure. Open path: student → balancer → CampusClip → cache, with a dashed miss to the store. The 302 goes back along that path. A click queue is not on it.

How an open becomes a 302

1. Hit the balancerStudent does not pick a host.
2. Cache, then storeHit answers from the copy; miss loads the store and fills the cache.
3. Reply, then maybe queueSend the 302. Enqueue the click if you want a counter.

4The store: one table, then replicas or shards

CampusClip's store is one table: short code → long URL. For this campus that table is small. The first scaling question is not "how many shards does industry use". It is the shape of the load. The 9:00 minute is read-heavy: many opens of a few codes. A cache plus a read replica (a copy of the table that serves lookups, while one primary takes inserts) absorbs that shape. The replica can lag the primary — a brand-new code might miss on the replica for a moment; read-your-write from the primary if the teacher immediately clicks their own link.

Write-heavy is the other shape: so many inserts that one primary cannot accept them. Then you shard — split rows across nodes by key so writes fan out. Replicas do not fix that: they multiply read capacity and often make write fan-out worse. CampusClip's classroom paste rate is not that shape; we name the lever so you can recognise it, not so we can invent a shard count.

Figure. Writes hit the primary; dashed edges show reads served from replicas. That is the read-heavy path. Sharding (not drawn) splits the write set when replicas are not enough.

How each path absorbs load

1. ReplicatePrimary ships changes to replicas; opens can move off the primary.
2. Accept lagAsync replicas may be briefly stale — or read-your-writes from the primary.
3. ShardPartition rows by key so each node owns a slice of writes and storage.

5Placing codes when nodes join

If CampusClip ever shards the table, each short code needs an owner node. Ordinary hash-modulo placement (\mathrm{node} = \mathrm{hash}(\mathrm{code}) \bmod N) reshuffles almost every code when N changes — adding a fifth store node would move nearly all rows. Consistent hashing places codes and nodes in the same ordered space so that when a node joins or leaves, only about 1/N of the codes move on average; the rest keep their previous owner.

That 1/N is an average over the keyspace, not a production measurement. For N = 5 after a join, about 1/5 = 0.2 of codes rematerialize. Cache rings use the same idea: adding a cache node should not empty every other node.

Picture a circle. Nodes sit at hash positions; each short code walks clockwise to the first node it meets. Add a node: only codes that now hit the newcomer move — roughly one N-th of the keyspace — not a full reshuffle.

How remapping stays small

1. PlaceHash codes and node ids into the same ordered space.
2. OwnEach code belongs to the next node clockwise (or the nearest successor).
3. ChurnAdd or remove one node: only codes in its arc move — about 1/N of them.

6A capacity sketch from numbers we stated

We can now multiply only what we already gave CampusClip. Host H finishes 20 redirects/s at W = 0.2 s, so L = 4 in-flight. A 250-byte reply at 20/s is 5000 bytes/s out. At 9:00, λ = 10/s so ρ = 0.5 and L = 2. The 40/s burst on one host is 20/s excess — add a second host, or the wait pile grows.

The code space: six characters from 62 symbols is 62^6 = 56\,800\,235\,584 possible codes. We do not need that many for 800 students. The number is here so you see the minting scheme has room, not so we can claim a worldwide shortener. Writes stay synchronous; clicks and mail may queue at the 20/s worker we already sized.

Figure. Only stated CampusClip numbers: L = 20 × 0.2 = 4 in-flight, outbound 20 × 250 = 5000 bytes/s, and 62^6 = 56,800,235,584 codes. No production QPS is invented.