All activity

ANN at Scale: HNSW

Give up on exact, and you can search a billion vectors in milliseconds. This is the graph that makes it happen.

Part five of the search series. Exact kNN is O(N) and hopeless at scale, so production vector search gives up exactness for speed with approximate nearest neighbor. This explains the dominant method, HNSW: navigable small-world graphs, greedy search, the layer hierarchy, and the M / efConstruction / ef knobs, with an interactive graph-search explorer.

• Search

Caching: Don't Do the Same Work Twice

The fastest work is the work you never do. A cache keeps a copy of an answer close by, so the next time someone asks, you hand it over instead of computing it all again. Here is how caches actually work: where they live, how reads and writes flow through them, and why they have to forget things.

A from-the-ground-up look at caching. Why it works (keep the answer close), where caches live (browser, CDN, app, database), the cache-aside read pattern (the hit and the miss), the three write patterns (through, back, around), and eviction (why a full cache must forget, with LRU). Everyday analogies, a hand-drawn diagram, and a visualizer per idea. The hard parts (invalidation, stampedes) and CDNs get their own pieces next.

• System Design

Speaking at DeveloperWeek

Generating working MCP servers straight from the OpenAPI specs you already have: the mechanical field mapping, why it takes a library and not a script, the production traps, and the guardrails to set before an agent touches real users.

• MCP

Vector Search (kNN)

When you stop comparing characters and start comparing coordinates, search can finally match meaning.

Part four of the search series. Keyword and fuzzy search match characters, so they miss synonyms. Vector search embeds text into geometry, where similar meaning becomes nearby points. This covers embeddings, the two distance metrics (cosine vs euclidean), exact k-nearest-neighbor search, and the scaling wall that forces the approximate methods in the next part. With an interactive kNN explorer.

• Search

How a Load Balancer Sticks

Sometimes you want the opposite of spreading traffic evenly: send the same client, or the same request, to the same server every time. That is stickiness, and it runs from a simple hash all the way to the elegant trick of consistent hashing.

A dedicated look at the sticky load-balancing rules, the ones that send the same key to the same server. Why you want it (sessions and caches), then each rule with its own analogy and visualizer: source-IP hash, URL hash, the reshuffling problem, consistent hashing (the ring), Maglev (a fast table), and cookie-based sticky sessions. Part two of two; part one covered the even-spreading rules.

• System Design

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

openapi-mcp

Turn any OpenAPI spec into an MCP server

Turns an OpenAPI 3.x specification into a working Model Context Protocol server, exposing the generated tools over Streamable HTTP for any MCP client with no glue code.

• Java 21
• Spring Boot 3
• MCP
• Gradle

• AI Agent Harness

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

A Field Guide to MCP

What the Model Context Protocol is, the pieces it is made of, and the map of the rest.

The Model Context Protocol is how an AI application reaches the tools and data it needs. By mid-2026 it is a Linux Foundation standard with an official registry and support across the major platforms. This opening piece lays out the problem, the client-host-server architecture, the six primitives, and the map, anchoring a five-part series.

• MCP