Run a mock round

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.

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.

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.

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.