Reverse Proxies, the Routing Problem, and the Architect's Role

Before moving to the deeper parts of HLD, I want to clear up one common misconception about how data travels, look at the routing problem that drives the rest of the curriculum, and step back to understand what it actually means to think like an architect.

The Load Balancer as a Reverse Proxy

I used to assume that once the LB forwards a request, the backend server sends the response directly back to the user. That is not how it works.

The Load Balancer acts as a Reverse Proxy:

1. Request Termination: The client's request ends at the LB. The LB is the one the client is talking to.
2. New Request: The LB creates a new internal request to the backend server.
3. The Return Path: The backend sends the response to the LB, and the LB forwards it to the user.

This "middleman" setup is what lets the LB hide your internal server IPs, enforce security policies, and handle SSL termination in one place.

The Random Routing Problem

If we have 500 servers, the naive approach is to pick one at random for each request. That breaks almost immediately.

Imagine James adds a bookmark. The LB sends it to Server A. The next day James wants to view it. The LB randomly picks Server B. Server B has no local record of James and returns nothing.

ExpandSharding and Intelligent Routing Roadmap

This is the Routing Challenge: you need a deterministic way to ensure that James's reads always go to the same place his writes landed. The two tools that solve this are Consistent Hashing (intelligent routing) and Sharding (distributed storage). These are the pillars of the curriculum ahead.

The HLD Roadmap

The rest of this track is structured around four phases:

Phase 1 - Scaling Fundamentals

Solving the routing problem with Load Balancing Algorithms, Sharding, and Consistent Hashing. This is where most system design interviews begin.

Phase 2 - Caching and Performance

How to handle massive read loads using caches. Case studies from real systems: Scalar's million-user contests, Facebook's global News Feed.

Phase 3 - Data Integrity and Consistency

The CAP Theorem and PACELC. The impossible trade-offs between availability and consistency that every distributed system eventually has to make.

Phase 4 - Advanced Case Studies

Applying everything to real problems: Google Typeahead, Uber nearest-driver search, WhatsApp real-time delivery.

From Developer to Architect

Most engineers start in one of two tracks:

• The Developer: Writes the logic. Knows what to build, but has little visibility into how it scales.
• The DevOps Engineer: Configures the infrastructure. Knows how to set up a load balancer, but not always why the architecture was designed that way.

High-Level Design is the bridge. When you understand HLD, you are not just following a blueprint - you are the person who draws it. You understand why you chose three load balancers instead of one, why the database is sharded on user ID rather than timestamp, and what breaks first when traffic triples overnight.

That is the move from senior engineer to Staff Engineer or Architect: the shift from implementing decisions to making them.

[!IMPORTANT] HLD is open-ended. In system design interviews, the depth of the conversation follows your resume. If you list "Nginx," expect a deep dive on reverse proxying and upstream configuration. Broad architectural fluency is the foundation - specifics follow from what you have actually built.

The next chapter starts where the routing problem gets concrete: Load Balancing and Consistent Hashing.

The Essentials

1. A Load Balancer is a Reverse Proxy - the client talks only to the LB, the LB creates a fresh request to the backend, and the response travels back through the LB. This is what enables IP hiding, SSL termination, and security enforcement in one place.
2. Random routing breaks stateful systems - if James writes a bookmark to Server A but the next request hits Server B, the data is simply not there. Solving this deterministically is what Consistent Hashing and Sharding exist for.
3. HLD is the bridge between the developer who writes logic and the architect who designs systems - mastering it is the shift from implementing decisions to making them.

Further Reading and Watching

• ByteByteGo - Consistent Hashing - The clearest visual explanation of how consistent hashing solves the random routing problem introduced in this post.
• Martin Kleppmann - Designing Data-Intensive Applications (overview) - The foundational book for understanding the trade-offs in distributed systems that the rest of this HLD track is built on.