Trade-Offs — Core Concepts
Interview Relevance: High — Demonstrating the ability to weigh different options and choose the right one for the specific system requirements is a key signal of seniority.
Master Trade-Off Table
This is the trade-off decision log that demonstrates seniority:
NOTE
Alternate production variant: The redirect type (302) and consistency level (QUORUM) selected below assume a requirement for strict server-side analytics and no dirty reads. This diverges from the baseline 5-step story which allows eventual consistency (ONE) and treats analytics as out-of-scope (allowing 301 redirects).
| Decision | Option A | Option B | We Chose | Reason |
|---|---|---|---|---|
| Redirect type | 301 Permanent | 302 Temporary | 302 | Need server-side analytics tracking |
| Database | MySQL (SQL) | Cassandra (NoSQL) | Cassandra | 182 TB scale, key-value access pattern, built-in sharding |
| Sharding key | user_id | short_code | short_code | Primary access is by short code, avoids hotspots |
| Consistency level | Strong (QUORUM all) | Eventual (ONE) | QUORUM | Dirty reads on redirects are unacceptable |
| Cache eviction | LFU | LRU | LRU | Recency is a better proxy for redirect popularity |
| ID generation | Hash + truncate | Snowflake + Base62 | Snowflake | No collision risk, no DB lookup for uniqueness check |
| Expiry mechanism | Cron scan | Cassandra TTL | Cassandra TTL | Native O(1) expiry, no full-table scans |