Growing past one box

1CampusClip, the service we will design

CampusClip is a campus URL shortener. A teacher pastes a long LMS or Drive link; CampusClip stores that long URL and hands back a short campus link such as clip.campus/a3k9. A student taps the short link; CampusClip looks up the code and replies with a redirect to the long URL.

Every later topic uses this same app. We will never switch to a different product. When a number appears, it is a number we state for CampusClip in this course — not a claim about how large shorteners run in industry.

Figure. Teacher writes a mapping; student reads it. CampusClip sits in the middle and owns the short code.

What CampusClip does

1. PasteTeacher submits a long URL.
2. StoreCampusClip keeps code → long URL.
3. RedirectStudent hits the short link and is sent on.

2Vertical vs horizontal scaling

Suppose CampusClip still runs as one program on one host. Vertical scaling (scale up) means giving that one host more CPU, RAM or disk. It is simple: the code does not have to know about other machines. The cost is a hard ceiling — one box can only grow so far — and a single point of failure: if that host dies, every short link on campus dies with it.

Horizontal scaling (scale out) means running the same CampusClip program on more than one host and splitting student traffic among them. Capacity then grows by count, not by one machine's ceiling. The cost is that the program must tolerate more than one instance, and anything it used to keep only in that process's memory — the code → URL table, a login session — must live somewhere those instances can all see.

Figure. Left: one tall host (scale up). Right: three smaller hosts (scale out) — capacity grows by count.

How the choice lands

1. Scale upBigger instance on one host — no distribution logic, until hardware caps out.
2. Scale outMore identical hosts; any one can die without taking CampusClip down.
3. Cost of outNeeds a load balancer and a store that is not in-process memory.

3Load balancing

Once CampusClip has more than one host, a student must not have to pick which host to hit. A load balancer sits in front of the pool and owns one address. Every open of clip.campus/a3k9 lands there first; the balancer then chooses a healthy CampusClip host and forwards the request.

Two common policies: round-robin cycles through the pool in order; least-connections sends the next request to the host with the fewest open connections. Health checks probe each host; a host that fails its check is removed from the pool so traffic stops landing on a dead process. The balancer is therefore also where high availability usually starts — but it does not, by itself, make the code multi-instance safe.

Figure. Students hit one balancer; it fans out to healthy CampusClip hosts S1–S3. A failed health check removes a host from the pool.

How a request is placed

1. ArriveStudent hits the balancer address, not a specific CampusClip host.
2. PickPolicy chooses a healthy backend — round-robin or least-connections.
3. Fail outFailed health checks drop a host until it recovers.

4CAP theorem under partition

The moment CampusClip has more than one machine that must agree on the same code → URL table, a network partition can split those machines so they cannot talk. The CAP theorem says that during a partition a distributed store can keep at most two of Consistency, Availability and Partition tolerance. Real networks do partition, so Partition tolerance stays; the live choice is Consistency versus Availability.

A CP CampusClip refuses or errors rather than hand out two different long URLs for the same short code. An AP CampusClip keeps answering on both sides of the split and repairs later (eventual consistency) — a student might briefly follow a stale mapping. SQL stores often lean CP; many NoSQL stores lean AP. That is a design preference, not a law that every SQL or NoSQL product must obey.

How a partition forces the choice

1. Partition hitsSome replicas cannot talk; both sides may still receive student traffic.
2. CP pathServe only when a quorum can agree — some opens see errors or timeouts.
3. AP pathServe on both sides; reconcile after the partition heals.

5Availability nines

Availability is the fraction of time CampusClip answers. It is usually quoted as "nines": 99.9% is three nines. That number is a downtime budget, not a vibe. Using 365.25 \times 24 = 8766 hours in a year, three nines allows 0.001 \times 8766 = 8.766 hours down — about 8.76 hours. Four nines (99.99%) is a tenth of that, about 52.6 minutes. Five nines is about 5.3 minutes.

Each extra nine is roughly a 10\times tighter downtime budget. Plan CampusClip maintenance and failover against that number. "Highly available" without a nine-count does not tell you whether a two-hour campus outage is inside the budget.

Figure. A year is 365.25 × 24 = 8766 hours. Three nines (99.9%) allow 0.001 × 8766 = 8.766 hours down. Four nines are about 52.6 minutes; five nines about 5.3 minutes. Each extra nine is roughly a 10× tighter budget. Boxes are equal; downtime is not drawn to scale.

How to turn a percentage into hours

1. Year lengthUse 365.25 \times 24 = 8766 hours in a year.
2. Downtime fractionDowntime fraction = 1 - availability.
3. Hours downMultiply: downtime hours = (1 - A) \times 8766.