Evaluation
In one line: after four chapters of evaluations that could have been pasted into any design, this one actually evaluates this design. One of its five claims is still wrong.
Requirements compliance
| Requirement | Techniques |
|---|---|
| Availability | Daily backups to S3 · global server load balancing · rate limiters to limit each user's resource allocation |
| Scalability | Horizontal sharding · consistent hashing · MongoDB as the NoSQL database |
| Readability | Base-58 encoder · removal of non-alphanumeric characters · removal of look-alike characters |
| Latency | Negligible encoding delay · MongoDB's low read latency · distributed cache |
| Unpredictability | Randomly selecting an ID from the pool of unused IDs |
This evaluation names its own mechanisms — the first in the module to do so
Worth pausing on, because the module's record has been poor.
Yelp credited caching and skipped the quadtree. ChatGPT covered 0.16% of the latency budget. Newsfeed and Instagram both listed only techniques that would apply to any system.
This one names base-58 encoding, the specific characters removed, random selection from the ID pool, and encoding's negligible cost. Every one of those is specific to this chapter and appears nowhere else in the module.
The readability row in particular is exactly right and exactly this design's mechanism.
An evaluation that mentions things only your design does is evaluating your design. That is the test earlier chapters failed and this one passes.
The unpredictability row is the one that does not survive Lesson 10
Unpredictability: "Randomly selecting and associating an ID to each request, from the pool of unused and readily available unique IDs."
Lesson 10 did the arithmetic. Random selection defeats an attacker who predicts "what comes after the last ID I saw?" It does nothing against an attacker who tries random strings, because guessability is a function of how full the space is, not the order you filled it.
At the advertised 6-character minimum:
58^6 = 38 billion strings
12 billion stored
-> 31.5% occupancy, roughly one guess in three succeeds
The saving grace, also from Lesson 10, is that IDs drawn from a 64-bit range are 11 characters 97.7% of the time, so real density is about 5 × 10⁻¹⁰ and the system is safe.
But that means the evaluation credits the wrong mechanism. Unpredictability comes from the space being enormous, not from randomizing selection within it. And the chapter's own conclusion hints at the gap:
Security can be improved by adding a salt to the unique ID before encoding. This makes the resulting short URLs harder to predict.
A salt is a real improvement over sequential issuance — but again, it changes the mapping, not the density. If a third of the space were occupied, a salted mapping would still be a third occupied.
Name the property that provides the guarantee. Here it is sparsity, and the honest row would read: "unpredictability comes from a 64-bit ID space in which fewer than one in a billion values is assigned; random selection additionally prevents sequential enumeration."
The scalability row proposes machinery the load does not need
Scalability: horizontal sharding · consistent hashing · MongoDB.
All three are reasonable and none is required by volume. Lesson 3's corrected figures:
Storage: 6 TB over five years -> one machine Writes: 76 per second -> one machine, trivially Reads: 7,600 per second -> one machine, mostly served from a 66 GB cache
So sharding and consistent hashing are not solving a capacity problem. What they are solving is real, and the evaluation should say which:
Availability. Multiple nodes so no single failure takes the service down — which Lesson 2 argued matters unusually much here, because links live in artifacts you do not control.
Geographic distribution. Lesson 12's multi-region design, which is about latency and about surviving a regional outage.
Headroom. Growth beyond the stated assumptions.
The chapter's own NoSQL justification is better than the row suggests, and appears in its prose rather than the table: schema flexibility (not every URL has a UserID, since anonymous users exist) and operational ease of distribution. Both are genuine and neither is about scale.
When the corrected estimate says one machine, "scalability" must be argued from availability and geography, not from throughput.
Availability and latency are both well argued
Availability names four distinct mechanisms — replication of databases, caches and servers; the ID generation process relying on a replicable database rather than in-memory state; daily S3 backups; and GSLB.
The second is the interesting one and it connects to Lesson 11: putting used/unused ID state in a database rather than in a generating node's memory means losing a node does not lose the allocation state. That is a genuine availability argument specific to this design.
The chapter is also honest about the backup limitation: "in a worst-case scenario, this might result in the loss of URLs created since the last backup." Naming what a mitigation does not cover is rare and worth crediting.
Latency correctly identifies that encoding is negligible and that the cache does the work — and adds Lesson 12's grace-period argument: "there is typically a delay before a newly created URL is used, which allows time for data to replicate." That is the same structural observation, reused correctly.
What the design never addresses
Five gaps, in order of consequence.
The regional single point of failure. Lesson 12's admission — if the data centre owning a short URL is unreachable and the URL is uncached, it cannot be resolved. The availability requirement is the strongest in the chapter and this directly violates it. Replicating each region's records elsewhere is the fix.
Redirect semantics. 301 versus 302 is never discussed, and it determines whether updates work at all, whether you get click analytics, and how much traffic reaches you. Given the update requirement, it must be 302.
Read-side rate limiting. Lesson 4's point — redirectURL cannot require an API key, so reads cannot be limited per key. Reads outnumber writes 100:1 and have no stated protection.
Custom-alias predictability. Lesson 10 — users choose words, so that namespace is guessable by construction, regardless of the sparsity argument.
Analytics. The commercial purpose of most URL shorteners, structurally supported and never mentioned.
The first is the most serious, and it is the more striking because the chapter states the problem plainly and then lists availability as satisfied.
Key takeaway
This is the first evaluation in the module to name its own mechanisms — base-58, the specific characters removed, random ID selection — which is the test four earlier chapters failed. But the unpredictability row credits the wrong mechanism: random selection prevents sequential enumeration while guessability is a function of density, and the system is safe because IDs are 11 characters 97.7% of the time, not because selection is random. Scalability proposes sharding for a 6 TB, 76-write-per-second system — the real arguments are availability, geography, and schema flexibility, not throughput. Availability and latency are both well argued, and the chapter is honest about backup limits. The gap that matters most is the one it admits and then ignores: a regional failure makes every URL created there unresolvable.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "Replication and backups for availability, sharding for scale, base-58 for readability, caching for latency, and random IDs for unpredictability." |
| L5 | Questions the scaling claim: "6 TB and 76 writes a second doesn't need sharding for capacity — I'd argue for multiple nodes on availability and geography instead, which is a different and better justification." |
| Staff+ | Corrects the security claim and names the admitted gap: "random selection stops sequential enumeration, but guessability depends on density, not ordering. At six characters we'd be 31.5% occupied — one guess in three. We're actually safe because random 64-bit IDs are eleven characters almost always, so the guarantee comes from sparsity, and I'd state it that way. And the design admits its own worst problem: with the data centre encoded in the URL, a regional outage makes every link created there unresolvable, uncached. That directly violates the availability requirement, which matters more here than usual because the links live in artifacts we don't control. I'd replicate each region's records and treat the embedded location as a hint rather than an authority." |
Next: the whole design under interview conditions.