Run a mock round

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.

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.

Queues decouple producers from consumers, absorb traffic spikes, enable retries and fan-out, and improve resilience when a downstream service is slow or down.

Delivery semantics: at-most-once (may lose), at-least-once (may duplicate, the common default), exactly-once (usually means effectively-once via idempotent processing plus dedupe/deduplication keys). Design consumers to be idempotent.

Patterns: work queues with competing consumers, pub/sub topics, dead-letter queues for poison messages, retry with exponential backoff and jitter, and ordering via partition keys (Kafka) when order matters.

Tools: Kafka for high-throughput, replayable event streams; RabbitMQ/SQS for classic task queues. Discuss backpressure, consumer lag monitoring and schema evolution.