Bird
Raised Fist0

Vertical Scaling vs Horizontal Scaling - When Each Breaks and What to Do

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/7
Load Balancer

Receives client HTTP request and selects an app server

Load balancer uses round-robin to pick an application server

Protocol:HTTP/HTTPS
BeforeClient request arrives at load balancer
AfterRequest forwarded to one application server
Application Servers

Processes request and queries Redis cache for session data

App server checks Redis cluster for cached session info

Protocol:Redis GET/SET
BeforeApp server received request, no session data loaded
AfterSession data retrieved from Redis cache if present
Redis Cluster

Returns cached session data or misses

Redis cluster responds with session data or cache miss

Protocol:Redis GET/SET
BeforeRedis cluster holds cached session data shards
AfterSession data sent back to application server
Application Servers

Queries Cassandra cluster for user profile data

App server sends CQL query to Cassandra cluster

Protocol:CQL
BeforeApp server has session data, needs user profile
AfterUser profile data retrieved from Cassandra cluster
Cassandra Cluster

Executes distributed query and returns user profile

Cassandra cluster coordinates nodes to serve query

Protocol:CQL
BeforeCassandra cluster stores user profile data partitioned
AfterUser profile data sent to application server
Application Servers

Writes audit log entry to Vertical Scaling DB

App server inserts audit record into single-node DB

Protocol:SQL
BeforeVertical Scaling DB is under load with limited CPU/memory
AfterAudit log entry stored, DB load increased
Vertical Scaling DB

Processes write request but approaches resource limits

Single-node DB CPU and memory near max capacity

Protocol:SQL
BeforeDB operating normally with moderate load
AfterDB performance degrades, write latency increases
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│     Load Balancer     │
└────────────┬──────────┘
             │ HTTP/HTTPS
             ▼
┌───────────────────────┐
│  Application Servers   │
│  (Horizontally scaled) │
└───────┬───────────────┘
        │ Redis GET/SET
        ▼
┌───────────────────────┐
│    Redis Cluster      │
│  (Horizontally scaled)│
└───────┬───────────────┘
        │ CQL (Cassandra Query Language)
        ▼
┌───────────────────────┐
│  Cassandra Cluster    │
│  (Horizontally scaled)│
└────────┬──────────────┘
         │
         ▼
┌───────────────────────┐
│  Vertical Scaling DB  │
│  (Single node, limits │
│   vertical scale)     │
└───────────────────────┘
Design Rationale

This architecture illustrates the difference between vertical and horizontal scaling. The Load Balancer distributes client requests to multiple Application Servers, which are horizontally scaled to handle load. These servers query a Redis Cluster cache and a Cassandra Cluster database, both horizontally scalable to maintain performance at scale. However, audit logs are written to a Vertical Scaling DB, a single-node database that faces resource limits as load grows. This creates a bottleneck where vertical scaling breaks down due to hardware limits, while horizontal scaling components continue to handle increased traffic efficiently. Understanding where vertical scaling fails helps guide migration to distributed systems.

Primary Focus

✓

Practice

(1/5)
1. In a distributed database, at Step 4 the coordinator node receives conflicting writes from two partitions during a network split. What state does the coordinator enter immediately after Step 4?
easy
A. Coordinator marks the writes as conflicting and delays commit until partition heals
B. Coordinator commits both writes immediately to maintain availability
C. Coordinator rejects all writes to maintain consistency during partition
D. Coordinator forwards writes to a third node to resolve conflicts synchronously

Solution

  1. Step 1: Trace coordinator behavior at Step 4

    The coordinator detects conflicting writes from partitions and cannot commit both safely.

  2. Step 2: Understand conflict resolution

    It marks writes as conflicting and delays commit until partitions heal to avoid inconsistency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Coordinator defers conflicting writes until partition resolution [check]
Hint: Coordinator delays conflicting writes until partition heals [check]
Common Mistakes:
2. In a system where a stateless API Gateway forwards requests to stateful backend services, at step 4 the backend service checks the user's session cache. What happens if the session cache has expired?
easy
A. The backend service fetches session data from a centralized session store before processing
B. The backend service rejects the request immediately with an authentication error
C. The API Gateway retries the request to a different backend service
D. The backend service creates a new session and processes the request as a guest

Solution

  1. Step 1: Trace backend session cache check

    If session cache expired, backend must retrieve fresh session data to maintain stateful context.

  2. Step 2: Understand fallback mechanism

    Fetching from centralized session store ensures consistent session state before processing request.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Expired cache triggers centralized session fetch -> consistent state [check]
Hint: Expired cache -> fetch centralized session before processing [check]
Common Mistakes:
3. You must design a notification system that requires immediate user feedback on success or failure of each notification. Which communication approach is best suited for this requirement?
medium
A. Use synchronous HTTP calls with client-side timeouts and retries
B. Use fire-and-forget UDP packets for low latency
C. Use batch processing with delayed acknowledgment
D. Use an asynchronous message queue with eventual consistency

Solution

  1. Step 1: Identify requirement for immediate feedback

    Immediate success/failure feedback requires synchronous communication to confirm delivery.

  2. Step 2: Evaluate synchronous HTTP calls

    Synchronous HTTP with timeouts and retries provides immediate response and error handling.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Synchronous calls provide immediate feedback required by the system [check]
Hint: Immediate feedback needs synchronous calls with timeouts [check]
Common Mistakes:
4. At 10x scale, which component of a B-Tree index is most likely to become the bottleneck first, and why?
hard
A. The leaf nodes, because they grow linearly and cause large disk I/O for range scans
B. The root node, because it becomes a hotspot due to all searches starting there, causing contention
C. The internal nodes, because their fan-out decreases with scale, increasing tree height drastically
D. The buffer cache, because it cannot hold all index pages, causing frequent page faults

Solution

  1. Step 1: Understand B-Tree root node role

    All searches start at the root node, which must be accessed for every lookup, making it a hotspot under high concurrency.

  2. Step 2: Analyze scaling impact

    At 10x scale, root node contention increases as many threads compete to read/update it, limiting throughput before leaf or internal nodes become bottlenecks.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Root node hotspot causes contention first at scale [check]
Hint: Root node is single entry point, hotspot at scale [check]
Common Mistakes:
5. At 10x current scale, which component in the feed delivery system is most likely to fail first and why?
hard
A. The graph database, because it cannot handle the increased number of connection queries
B. The feed cache layer, because cache invalidation becomes too frequent and inconsistent
C. The feed delivery servers, because WebSocket connections are stateful and cannot be easily resharded
D. The recommendation model training cluster, because training data volume grows exponentially

Solution

  1. Step 1: Identify stateful bottlenecks at scale

    Feed delivery servers maintain WebSocket connections statefully, limiting horizontal scaling and resharding.

  2. Step 2: Compare other components

    Graph DB (The graph database, because it cannot handle the increased number of connection queries) and model training (The recommendation model training cluster, because training data volume grows exponentially) can be scaled horizontally or asynchronously. Cache layer (The feed cache layer, because cache invalidation becomes too frequent and inconsistent) faces challenges but is less critical than stateful connection limits.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Stateful WebSocket servers -> scaling bottleneck at 10x [check]
Hint: Stateful WebSocket servers block horizontal scaling [OK]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard