Run a mock round

Strategies:

• Cache-aside (lazy loading): app checks cache, on miss reads DB and populates. Most common.
• Read-through: cache library fetches on miss.
• Write-through: write to cache and DB together for consistency.
• Write-behind: write to cache, flush to DB asynchronously for throughput with some durability risk.

Eviction: LRU/LFU/TTL. Place caches at multiple layers: client, CDN, application (Redis/Memcached), and database.

Failure modes:

• Stampede/thundering herd: many requests miss the same key; use locks, single-flight or jittered TTLs.
• Cache penetration: repeated misses for non-existent keys; cache negatives or use a bloom filter.
• Stale data: invalidation is hard; set TTLs, publish invalidation events, or version keys.
• Hot key overload: shard or replicate the key.

A distributed store can guarantee only two of three during a network partition: Consistency (every read sees the latest write), Availability (every request gets a non-error response) and Partition tolerance (the system keeps working despite dropped messages). Since partitions are unavoidable in real networks, the real choice under partition is consistency vs availability.

• CP systems (HBase, ZooKeeper, etcd) reject requests to stay consistent, good for coordination and financial ledgers.
• AP systems (Cassandra, DynamoDB in some modes, Riak) stay available and reconcile later with eventual consistency, good for shopping carts, feeds and telemetry.

PACELC extends this: even without partitions you trade latency against consistency. Also mention tunable consistency (quorum reads/writes) and that most real systems are a hybrid per operation.

SQL (relational): rigid schema, ACID transactions, powerful joins and ad-hoc queries, mature tooling. Excel at structured, relational data with integrity requirements such as finance, inventory and booking systems.

NoSQL families:

• Document (MongoDB): flexible schema, good for evolving content and per-entity aggregates.
• Key-value (Redis, DynamoDB): extremely fast simple lookups, sessions, caches.
• Wide-column (Cassandra, HBase): high write throughput across many nodes.
• Graph (Neo4j): relationship-heavy domains like social or recommendation graphs.

Decision drivers: access patterns, consistency needs, scale shape, query flexibility and team expertise. Many systems are polyglot: a relational core with a search index (Elasticsearch) and a cache (Redis). Avoid choosing NoSQL only to dodge schema design.

Requirements: shorten a long URL, redirect quickly, handle ~100M new links per day with a 100:1 read-to-write ratio.

API: POST /api/links {longUrl} -> {shortUrl}; GET /{code} -> 301/302 redirect.

Key generation: base62 encode a global counter, or a distributed ID generator (Snowflake), or a random code with collision retry. Counter-based is compact and collision-free but predictable; random is unguessable but needs a uniqueness check.

Storage: a key-value store (DynamoDB/Cassandra) mapping code -> longUrl, plus a relational table for ownership and analytics. Reads dominate, so cache hot codes in Redis with a high hit rate.

Scale: stateless redirect service behind a load balancer, CDN/edge caching for popular links, read replicas, and async click analytics via a queue (Kafka) so logging never blocks redirects.

Extras: custom aliases, expiry, abuse detection, rate limiting, and 301 (permanent, cacheable) vs 302 (trackable) choice.