Writing on systems engineering

How a Load Balancer Spreads the Load

The load balancer's first job is picking which server gets each request. There is a small family of rules for that, from dealing cards in turn to glancing at two servers and choosing the emptier. Here they are, one at a time.

A dedicated look at the load-balancing algorithms that spread traffic across servers. The static-vs-dynamic split, then each rule in turn with its own analogy and visualizer: round-robin, weighted round-robin, least-connections, least-response-time, and power-of-two-choices. Part one of two; part two covers the sticky ones (hashing and affinity).

• System Design

The Gateway: One Front Door

One front desk that every request passes through, so each service behind it does not have to check IDs, enforce limits, and route traffic on its own. It is also where a confusing family of names lives: gateway, reverse proxy, load balancer.

A deep look at the gateway, the third building block from the request-path overview. The cross-cutting jobs it does once for everyone (authentication, routing, TLS, rate limiting), how a gateway relates to a reverse proxy and a load balancer (they are one overlapping family), the difference between a forward and a reverse proxy, and where rate limiting fits. Everyday analogies, a hand-drawn diagram, and a visualizer per idea.

• System Design

DNS: The Internet's Phone Book

Computers find each other by number, not by name. DNS is the phone book that turns guptasachinn.com into an address a machine can dial, and it is quietly one of the most important systems on the internet.

A deep look at DNS, the building block introduced in the request-path overview. How a name becomes an IP address, the lookup chain from your resolver up to the authoritative server, why answers are cached (TTL), and how DNS does more than lookups: sending you to the nearest server and routing around a dead one. Everyday analogies, a hand-drawn diagram, and a visualizer per idea.

• System Design

Load Balancers, Up Close

One web address, but many identical servers behind it. The load balancer is the host that decides who goes where, notices when a server dies, and can even read a request to route it. Here is everything it does.

A dedicated look at load balancers, the building block introduced in the request-path overview. How it chooses a server (round-robin, least-connections, weighted, sticky), how health checks notice a dead server and route around it, the difference between layer 4 and layer 7 balancing (route by the envelope or open the letter), and how the load balancer itself avoids being a single point of failure. Everyday analogies, a hand-drawn diagram, and a visualizer per idea.

• System Design

How a Request Finds a Server

Type a web address, hit enter, and a page appears. Behind that is a small journey: your request must find one server out of millions, then get past the front door. Three things make it happen: DNS, a load balancer, and a gateway.

Day three of the System Design series, and the first building blocks. When someone uses your system, the very first thing that happens is their request finding a server. This walks the journey: DNS turns a name into an address, a load balancer spreads requests across servers, and a gateway is the shared front door for auth, rate limiting, and routing. Each explained with an everyday analogy first, a hand-drawn diagram, and its own interactive visualizer.

• System Design

Sizing a System on a Napkin

How big is this thing? You do not count, you estimate, the same way you guess jelly beans in a jar. Three quick multiplications tell you whether you need one server or a thousand.

Day two of the System Design series, and step two of the routine on its own: estimation. Learn to size a system with three numbers, throughput (requests per second), storage, and bandwidth, using rounded napkin math. Worked all the way through on the link shortener from day one. With a jelly-bean analogy, a hand-drawn diagram, and an interactive visualizer that rolls the numbers up as you go.

• System Design

How to Design a System

Faced with 'design something big', most people freeze or jump straight to a database. A good doctor never works that way: they run the same routine every time. Here is that routine for systems, in six steps.

Day one of the System Design series. Before any load balancers or databases, you need a way to think. This is the six-step routine, scope, estimate, API, data model, high-level design, then deep dive, walked through on a real example (a link shortener). With an everyday analogy, a hand-drawn diagram, and an interactive visualizer that shows the routine turning a vague prompt into a design.

• System Design

Understanding the Singleton Pattern in Java

A walk through the Singleton pattern in Java, from lazy initialization to thread-safe and double-checked locking, the Bill Pugh approach, and enum-based singletons, including how each holds up against serialization and reflection.

Why double Loses Precision and How to Avoid It in Java

A field-engineering note on the precision losses double quietly introduces in financial code, when BigDecimal is the right move, and the rounding patterns that keep statements reconcilable.

10 Unique Spark SQL Features You Won't Find in Oracle

Ten Spark SQL capabilities with no direct Oracle equivalent, from anti joins and explode to higher-order array transformations, and where they simplify real data pipelines.