System Design Interview Questions: Fundamentals Practice Quiz

This statement is true. Vertical scaling is simpler to implement because it involves only upgrading a single machine's hardware with no application-level changes. However, it hits a hard ceiling determined by the maximum specs available for a single server. Horizontal scaling bypasses this limit by adding more machines, at the cost of increased architectural complexity.

To reduce repeated expensive database queries and improve read scalability, engineers store the results of those queries temporarily in a fast in-memory store. This technique is called caching, and a widely used open-source tool for this purpose that supports rich data structures (strings, lists, sets, hashes, and more) beyond simple key-value pairs is Redis.

Horizontal scaling (adding more identical server instances behind a load balancer) is the correct approach. Because the service is stateless, any instance can handle any request, so distributing traffic across multiple servers directly increases concurrent-request capacity without touching the existing hardware. Vertical scaling also helps but requires downtime and has a hard ceiling.

The techniques that directly improve read scalability of a relational database are: read replicas (routing SELECTs to replica nodes adds horizontal read capacity), read-through caching (serving repeated reads from memory bypasses the database entirely), and sharding (partitioning data so each shard handles a smaller dataset and fewer concurrent queries). Increasing connection pool threads alone and rewriting stored procedures do not directly increase the database's read throughput.

The canonical order is: (1) single-server monolith, (2) move the database to a dedicated server, (3) add a load balancer with multiple stateless app servers, (4) deploy a caching layer, (5) shard the database. Separating the database onto its own server comes before horizontal app-server scaling because resource contention on a shared box must be resolved first, and a standalone DB server is a prerequisite for multiple app instances to connect to it correctly.

In cache-aside the application code owns the cache: on a read it checks the cache first, and on a miss it loads from the database, populates the cache, and returns. Writes go to the database and then invalidate (or update) the cache entry. Its main failure mode is the thundering herd / cache stampede — when a hot key expires, many concurrent requests all miss and hammer the database at once. Mitigate with request coalescing (single-flight), a short lock per key, or probabilistic early refresh.

Requirements. Two operations dominate: create (write a mapping, optionally with a custom alias and expiry) and redirect (look up a code and 30x to the long URL). The system is overwhelmingly read-heavy (100:1), so the redirect path is what we optimise. I'd confirm: are custom aliases required (yes), do links expire (optional TTL), and how precise must click counts be (approximate/eventually-consistent is fine). I'd use a 302 (temporary) redirect so we keep serving redirects through our system and can still count clicks; a 301 would let browsers cache and bypass us.

Capacity. ~40 writes/sec average, ~200/sec peak; ~4K reads/sec average, ~20K peak. Storage: ~6B links over 5 years; at ~500 bytes/row (code, URL, metadata) that's ~3 TB — comfortably shardable. Keyspace: base62 with 7 characters gives 62⁷ ≈ 3.5×10¹² codes, far more than 6B, so 7 chars (often padded to a fixed length) is plenty. The hot working set (recently/ popularly accessed links) is a small fraction of 6B, so a cache of tens of GB covers the bulk of redirect traffic.

Data model. A single mapping table/collection keyed by the short code: code (PK) → long_url, created_at, expires_at, owner_id. Point lookups by primary key suit a key-value store (DynamoDB/Redis-backed) or a sharded relational table sharded by code. Click counts live separately — incrementing a counter on every redirect would put write load on the read path — so clicks are emitted as events and aggregated asynchronously.

Short-code generation. Generate a unique 64-bit id (a distributed counter handed out in ranges per server, or a Snowflake-style id) and base62-encode it to get the short code; this guarantees uniqueness with no collision checks and no hotspot from a single shared counter. Custom aliases are written directly with a uniqueness check and stored in the same table, reserving that code. (A hash-of-URL scheme is the alternative but needs collision handling and breaks idempotency for duplicate URLs.)

Read/write paths. Write: allocate id → base62 → insert mapping → return the short URL. Redirect: a load balancer / CDN fronts stateless app servers; the server does a cache-aside lookup (code → long_url) in Redis, falling back to the store on a miss and populating the cache, then returns a 302. This keeps p99 well under 100 ms for cache hits. Expiry is enforced by TTL on both the row and the cache entry. Each redirect fires a lightweight click event onto a queue (Kafka) that a consumer aggregates into per-link counts.

Bottleneck & scaling. The bottleneck is the redirect read path at peak. We scale it with cache layers (most reads never touch the store), read replicas, and sharding the mapping store by code so lookups stay single-shard. Id generation scales by handing each server an independent id range (or using Snowflake), avoiding a single global counter as a SPOF. At 10× traffic, the cache absorbs most of it; we add cache nodes and replicas and, if needed, push redirects further to the edge.

Sticky sessions re-introduce per-instance state, unevenly distributing load and creating a soft single point of failure per user — defeating horizontal scalability. The canonical fix is to externalise session state to a shared distributed cache (e.g., Redis or Memcached) so the service remains truly stateless and any instance can handle any request without affinity.

In an AP system, both sides of a network partition keep accepting writes, so the 'likes' counts can diverge until the partition heals and the replicas reconcile. CRDTs such as a G-Counter are a good fit for merging those diverged counts, since increment-based counters combine without conflict. The application layer must tolerate eventual consistency, so reads can temporarily return stale counts until replicas catch up.

1. This is the hot shard (or write-hotspot) anti-pattern. Because event_id is monotonically increasing, new events always map to the uppermost range, which belongs to the last (highest-range) shard. All other shards only receive reads for historical data, never new writes. The range boundaries do not self-adjust, so the system is effectively single-shard for writes.

2. Consistent hashing maps both shard nodes and keys onto a circular hash ring. Each key is owned by the first node clockwise from the key's position on the ring. When a node is added or removed, only the keys between the new node and its predecessor (approximately K/n keys, where K is total keys and n is node count) need to be remapped and migrated. All other keys remain on their current nodes. This minimal disruption property — O(K/n) remapping vs O(K) for naive modular hashing — makes it operationally far superior for elastic, dynamically scaled shard clusters.