DEV Community: Zidane

What ACTUALLY Happens When You Type a URL google.com

Zidane — Sun, 16 Aug 2026 08:29:26 +0000

What ACTUALLY Happens When You Type a URL google.com

"If you’ve ever interviewed for a software engineering role, you’ve probably been asked: 'What happens when you type google.com into a browser and press Enter?'

Most developers give the standard textbook answer: Your browser looks up the IP via DNS, opens a TCP connection, sends an HTTP GET request, and renders the HTML.

While that answer might pass a Junior interview, it completely ignores the complex systems engineering happening under the hood. In reality, within less than 100 milliseconds, your operating system kernel, network interface card, BGP routers, TLS cryptographic primitives, and global edge networks execute a synchronized choreography involving dozens of low-level protocols.

Welcome back to Behind the Abstraction. Today, we’re upgrading the classic interview question to the Senior Engineer Edition. Let's strip away the browser magic and trace every single packet from your keyboard to Google’s data centers."

⏱️ CHAPTER 1: Hardware Interrupts & OS Kernel Space

"It all starts at the physical layer. The moment your finger depresses the Enter key, a circuit on your keyboard closes, sending an electrical signal to your computer’s interrupt controller.

The CPU pauses its current execution context and fires a Hardware Interrupt. The OS Kernel catches this via an Interrupt Service Routine (ISR), translating the raw hardware keycode into a readable character event.

The browser process—running in User Space—receives this input event. Chrome's UI thread checks the address bar. Is google.com a search query or a domain? Because it contains a top-level domain (.com), Chrome recognizes it as a URL.

If you have HSTS—HTTP Strict Transport Security—pre-loaded in your browser binary, Chrome immediately transforms http://google.com into https://google.com before a single network packet is even created, preventing plain-text downgrade attacks right at the starting line."

⏱️ CHAPTER 2: The Deep-Dive DNS Resolution Chain

"Before your computer can send data, it needs an IP address. But DNS resolution isn't just one API call—it’s a multi-tiered fallback hierarchy.

Browser Cache: Chrome checks its internal socket pool and DNS cache.
OS Cache & Hosts File: If missed, Chrome executes a system call (getaddrinfo on Linux/macOS) to query the OS DNS cache and check /etc/hosts.
Recursive Resolver: If still not found, the OS network stack constructs a UDP packet over port 53 and sends it to your configured Resolver (like your ISP router or 8.8.8.8).

If the resolver doesn't have the IP cached, it performs a full Iterative Traversal:

It queries the Root Name Server (.), which points to the TLD Server (.com).
It queries the .com TLD Server, which returns the IP of Google's Authoritative Name Server.
Finally, Google's Name Server returns an A record (for IPv4) or AAAA record (for IPv6), along with an Anycast IP address."

⏱️ CHAPTER 3: Packet Assembly & MAC Address Resolution

"Now that your OS has Google's IP address, it opens a network socket using the socket() system call. But your computer doesn't know how to physically transmit packets to an IP address across the internet—it can only transmit frames to a physical MAC Address on your local network.

This is where the ARP Protocol (Address Resolution Protocol) comes in. If your computer doesn't have your local Wi-Fi router's MAC address cached, it broadcasts an ARP Request across the local network: 'Who has IP 192.168.1.1?' The router replies with its physical hardware MAC address.

Now, your OS network stack encapsulates the payload like Russian nesting dolls:

Transport Layer: Adds a TCP Header specifying source and destination ports (Port 443 for HTTPS).
Network Layer: Encapsulates the TCP segment in an IP Packet with source and destination IP addresses.
Link Layer: Wraps the IP packet inside an Ethernet Frame containing your Router's destination MAC address.

The frame is converted into radio waves via Wi-Fi or light pulses over Fiber, leaving your machine."

⏱️ CHAPTER 4: BGP Routing, TCP Handshake & TLS 1.3

"Your packet travels across the global internet infrastructure using BGP (Border Gateway Protocol). Because Google uses Anycast Routing, the internet routes your request to the geographically closest Google Edge Point of Presence (PoP), rather than a distant central data center.

Once the packet arrives at Google’s edge router, the two machines must establish a connection:

TCP 3-Way Handshake: Your client sends a SYN, Google replies with SYN-ACK, and your client returns an ACK. Connection established.
TLS 1.3 Encryption Handshake: Because it's HTTPS, we need encryption. In modern TLS 1.3, this takes just one single round-trip (1-RTT). Your browser sends a ClientHello containing supported cryptographic cipher suites and a key share. Google responds with ServerHello, its digital certificate, and its public key share.

Using Elliptic-Curve Diffie-Hellman (ECDHE), both sides independently calculate a shared symmetric encryption key. From this millisecond onward, all traffic is encrypted end-to-end."

⏱️ CHAPTER 5: Edge Reverse Proxies & Browser Rendering

"Your browser sends an encrypted HTTP/2 or HTTP/3 (QUIC over UDP) GET request.

It hits a GFE (Google Front End) reverse proxy server. The GFE terminates the TLS connection, checks its edge cache, or routes the request through Google’s internal high-speed fiber network to a backend rendering service.

Google returns an HTTP 200 OK response along with the HTML payload, compressed via Brotli or Gzip.

Now, the browser's engine (like Blink in Chrome) takes over the Critical Rendering Path:

HTML Parser: Parses raw bytes into the DOM (Document Object Model) tree.
Pre-loader: Scans ahead to fetch external CSS, JavaScript, and images in parallel.
CSSOM & Render Tree: Parses CSS to build the CSSOM, combining it with the DOM to construct the Render Tree.
Layout & Paint: Calculates exact pixel coordinates for every element (Layout) and rasterizes them onto GPU layers (Paint).

Within less than a tenth of a second, the Google search bar appears on your screen."

⏱️ CHAPTER 6: Conclusion & Senior Mindset

"From an electrical signal on a keyboard to OS system calls, BGP packet routing, Diffie-Hellman cryptography, and GPU rasterization—typing a single URL triggers one of the most sophisticated engineering achievements in human history.

Understanding these layers isn't just about acing system design interviews. It’s what helps you debug production latency bottlenecks, optimize critical rendering paths, and build resilient, distributed architectures.

If you enjoyed peeling back the layers of this system abstraction, smash the Like button and subscribe to the channel!

Drop a comment below: What technical topic should we dismantle next? Thanks for watching, and I'll see you in the next one!"

#webzonezidane

#webzonetechtips

Inside Facebook's News Feed Architecture

Zidane — Sat, 08 Aug 2026 04:50:06 +0000

Inside Facebook's News Feed Architecture

Chapter 1: The Scale & SLA Challenge

"Every single day, more than three billion people around the globe unlock their phones and launch Facebook. Within a split second, a personalized feed appears on their screen—populated with photos from close friends, trending videos, group discussions, and targeted announcements. To the average user, this feels like magic. But beneath this clean mobile interface lies one of the most sophisticated and terrifyingly complex distributed systems ever engineered by humankind.

Consider the sheer operational scale. At any given moment, there are tens of thousands of candidate posts competing for space on your screen. If Facebook used a naive SQL database query to search through billions of posts across millions of friends, the network would freeze immediately. Yet, the engineering requirement—the strictly enforced Service Level Agreement—mandates that your news feed must render in less than three hundred milliseconds with high availability. How do you filter, rank, and assemble a totally unique content stream for billions of concurrent users in the blink of an eye? Let’s step behind the curtain and dissect the architecture."

Chapter 2: Graph Data Modeling with TAO

"To understand how Facebook processes connections, we must first look at how data is stored. Traditional relational databases rely on rows, columns, and expensive table JOIN operations. At Facebook's scale, joining user tables with post tables across global data centers is an absolute non-starter.

Instead, Facebook built TAO—which stands for The Association Object. TAO is a geographically distributed, read-optimized graph database. Rather than thinking in terms of database tables, TAO treats the entire social network as a massive graph made of Nodes and Edges.

Nodes represent concrete entities—such as a User, a Photo, a Comment, or a Page. Edges represent the directed relationships between these entities—such as 'User A is Friends with User B', 'User A Liked Photo C', or 'User B Commented on Post D'. TAO handles trillions of edge queries every day. By storing these relationships directly in memory across massive distributed caching tiers, TAO allows the system to traverse your entire social graph in mere microseconds."

Chapter 3: The Fan-Out Dilemma & Hybrid Architecture

"Once you have the social graph, how do you deliver a new post to a user’s friends? This brings us to one of the most famous system design tradeoffs: Fan-out on Write versus Fan-out on Read.

In a Fan-out on Write model—also known as the Push Model—when you publish a post, the system immediately writes a reference of that post into the inbox memory cache of every single one of your friends. When your friends open the app, reading their feed is blazingly fast because their timeline cache is already pre-assembled. This works brilliantly for regular users who have a few hundred friends.

However, this model completely breaks down when applied to high-profile accounts or celebrities. Imagine a global icon with one hundred million followers publishing a status update. Under a pure push model, a single button click would force the servers to write one hundred million database entries simultaneously. This causes catastrophic write amplification, CPU spikes, and severe network throttling—a scenario known as the Thundering Herd problem.

To solve this, Facebook deployed a Hybrid Fan-out System. For standard users with moderate friend counts, the system uses Fan-out on Write. But for celebrities, public figures, and viral pages, the system switches to Fan-out on Read. Their posts are stored in a dedicated hot cache. Only when you open your app does the backend pull that celebrity’s post on demand and merge it into your feed seamlessly."

Chapter 4: Multi-Tier Caching Infrastructure

"Latency is the ultimate enemy of user retention. Fetching feed items from persistent storage disks on every scroll is far too slow. To achieve sub-millisecond retrieval speeds, Facebook engineered one of the world's largest distributed RAM caching infrastructures, heavily built around optimized Memcached clusters.

When you scroll your feed, almost nothing comes directly from a hard drive; your feed is served almost entirely out of RAM. Facebook created Mcrouter, an open-source memcached protocol router, to manage traffic across millions of cache nodes globally.

To prevent cache stampedes—where thousands of application threads request the exact same missing key simultaneously—the caching layer employs clever primitives like Leases. If a key is missing, the cache hands out a lease token to only ONE worker process to rebuild the data, while telling all other requests to wait or serve stale data gracefully. This architecture guarantees that database layers remain shielded even during massive global viral events."

Chapter 5: The 4-Stage AI Ranking Engine

"Having a list of candidate posts from your friends and pages is only half the battle. Out of ten thousand potential items, which twenty posts should appear at the top of your feed right now? This is where Facebook’s Multi-Stage AI Ranking Pipeline takes over.

The machine learning pipeline processes content through four distinct stages:

Stage One is Candidate Generation. The system pulls roughly ten thousand eligible posts from your friends, groups, followed pages, ads engines, and recommended topics.

Stage Two is Lightweight Scoring. Running complex deep learning models on ten thousand items in real time would crush server compute. So, a lightweight scoring model quickly evaluates basic metadata—filtering out old posts or low-relevance content—narrowing the pool down to about five hundred high-probability candidates.

Stage Three is Deep Neural Network Ranking. This is the core machine learning phase. Deep neural networks evaluate thousands of contextual features per post in real time: How often do you interact with this author? Is it a high-definition video or a text update? Are you on Wi-Fi or a weak 4G connection? The AI calculates specific predictive probabilities: The probability you will click, the probability you will leave a comment, the probability you will share, or the probability you will watch the video to completion. These probabilities are combined into a final weighted score.

Stage Four is Diversity and Policy Filtering. Before the top-ranked posts hit your screen, the system enforces business rules. It ensures variety so you don't see ten posts in a row from the same person, injects sponsored advertisements at fixed intervals, and strips out policy-violating misinformation or clickbait."

Chapter 6: Real-Time Event Streaming & Invalidation

"A news feed is not a static webpage; it is a living, breathing stream. When you like a post or post a comment, that action must instantly influence what you and your friends see next.

To handle millions of concurrent user interactions per second, Facebook uses an Asynchronous Event-Driven Architecture. Every click, reaction, comment, or scroll event is captured by edge proxies and published into distributed log streams like Apache Kafka or Facebook's internal streaming engines.

Stream processing engines consume these events in real time to update feature stores, recalculate user engagement signals, and invalidate stale cache entries. If a post goes viral with thousands of angry reactions, real-time analytics pipelines notify the ranking model to adjust its distribution score dynamically—all without blocking the main user application thread."

Chapter 7: Client-Side Optimization & GraphQL

"All this backend power would be useless if the mobile client took seconds to parse and render the response. This is why Facebook pioneered GraphQL.

Instead of traditional REST APIs that return fixed, bloated JSON payloads containing unnecessary data fields, GraphQL empowers the mobile app to request exact data fields—no more, no less. On a slow mobile network, the client can ask for just post titles, author avatars, and image URLs, drastically reducing network payload size.

Furthermore, the mobile app utilizes Pre-fetching and Cursor-based Pagination. As you scroll near the bottom of your screen, an Intersection Observer triggers a subtle background request to pre-fetch the next batch of five posts. By the time your thumb swipes up, the content is already cached locally in device memory, creating the illusion of an infinite, zero-latency scroll."

Chapter 8: Conclusion & Key System Design Takeaways

"Building a system that serves personalized content to three billion people under three hundred milliseconds requires mastering system design trade-offs.

Let's recap the core engineering principles behind Facebook’s News Feed: First, leverage specialized databases like TAO to traverse graph relationships in memory. Second, adopt a Hybrid Fan-out strategy to balance write amplification against read performance. Third, rely on multi-tier in-memory caching with Memcached to keep disk I/O at near zero. Fourth, utilize a multi-stage AI ranking pipeline to narrow down candidates efficiently. And finally, streamline client communication with GraphQL and smart pre-fetching.

That is the hidden engineering marvel powering the world's largest social feed every single second. Thank you for tuning in!"

How Uber Handles 50,000 Requests per Second Without Crashing: A System Design Deep Dive

Zidane — Thu, 06 Aug 2026 14:44:37 +0000

How Uber Handles 50,000 Requests per Second Without Crashing: A System Design Deep Dive

It is 5:00 PM on a rainy Friday in Manhattan. Subways are delayed, rain is pouring down, and within a single second, over 50,000 users pull out their phones and tap "Request Ride".

At that exact moment, 20,000 drivers are navigating crowded city streets, their mobile devices sending precise GPS updates back to the cloud every 4 seconds.

To a backend engineer, this scenario sounds like a recipe for catastrophe:

Hundreds of thousands of persistent TCP connections.
Massive, continuous database write streams.
Complex spatial proximity queries executing in real time.

If your database locks for just two seconds, users cancel their requests. If latency spikes past 500 milliseconds, the entire platform risks a cascading outage. Yet, behind Uber’s clean mobile interface, an intricate system matches passengers with nearby drivers in under 100 milliseconds.

How does Uber route this immense, highly stateful traffic without dropping a single packet? The answer lies in an architecture that decouples traditional web pipelines and leverages hexagonal spatial indexing.

The Illusion of Traditional Load Balancing

When developers study load balancing, they typically picture a traditional, stateless architecture:

$$\text{Client} \xrightarrow{\quad \text{HTTP Request} \quad} \text{NGINX Balancer} \xrightarrow{\quad \text{Round-Robin} \quad} \text{Server A / Server B}$$

This stateless model works exceptionally well for e-commerce platforms or content portals. If Server A fails, NGINX silently redirects your request to Server B. It doesn't matter which server fetches your shopping cart from the database because state lives securely in a centralized storage layer (like PostgreSQL or Redis).

Why Stateless Round-Robin Fails for Ride-Hailing

Ride-hailing is fundamentally stateful, highly dynamic, and bound to physical geography:

The Database Write Bottleneck: Storing driver locations in a relational database forces your cluster to execute tens of thousands of spatial write operations per second (UPDATE drivers SET location = ...). The resulting disk lock contention will paralyze even high-end database clusters.
The $N+1$ Network Hop Problem: Suppose Passenger A in Times Square requests a ride. If Passenger A's request hits Server 1, but nearby Driver B's location data is stored in memory on Server 2, Server 1 must query every other node in the data center to locate surrounding drivers. Inter-node network latency explodes exponentially.

Uber realized early on that off-the-shelf load balancers could not solve this problem. They needed a multi-tiered pipeline that separates network protocol handling from spatial in-memory state.

The Three-Tier Architecture Overview

To solve throughput and spatial coordination simultaneously, Uber engineered a distinct three-tier load balancing network:

┌─────────────────────────────────────────────────────────────┐
│ TIER 1: Edge Defense & L4 Transport Routing                 │
│ (IPVS / Hardware Switches — High Packets/Sec, No TLS Parse) │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│ TIER 2: L7 Application Gateways                             │
│ (Envoy Proxy — Path Routing, JWT, Circuit Breaking)         │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│ TIER 3: Stateful Application Ring                           │
│ (Ringpop + H3 Spatial Indexing — In-Memory Sharding)        │
└─────────────────────────────────────────────────────────────┘

Tier 1: High-Speed Perimeter Routing at Layer 4

At the outer perimeter of Uber’s infrastructure sit Layer 4 (L4) load balancers, implemented using Linux IP Virtual Server (IPVS) and high-performance hardware switches.

Why Layer 4 First?

Layer 4 operates strictly at the transport layer (TCP/UDP). An L4 balancer evaluates only:

Source IP and Port
Destination IP and Port

It does not decrypt TLS certificates, parse HTTP headers, or examine JSON payloads. By skipping CPU-intensive SSL termination and layer-7 packet inspection, a single L4 edge node can process millions of packets per second with near-zero CPU overhead.

Tier 1 acts as a massive traffic filter and distributor, absorbing raw internet connections, terminating TCP streams, and evenly fanning packets out to the Tier 2 proxy layer.

Tier 2: Intelligent Microservice Gateway with Envoy Proxy

Once traffic passes the L4 edge layer, it hits Tier 2 Layer 7 (L7) load balancers powered by Envoy Proxy.

At Layer 7, the proxy decrypts the HTTP payload and inspects request context:

Path-Based Routing: A request to /api/v1/payments routes directly to the isolated Payment Service cluster, whereas /api/v1/dispatch routes to the Dispatch Engine.
Authentication & Validation: Envoy parses JSON Web Tokens (JWTs) at the proxy level, rejecting unauthorized requests before they ever reach internal application code.

Resiliency Patterns: Circuit Breaking & Shedding

When handling 50,000 requests per second, microservice dependencies will periodically slow down. Envoy enforces strict resilience patterns:

Circuit Breaking: If the Payment Service experiences a spike in latency, Envoy trips a circuit breaker immediately, returning a fallback response rather than letting queued requests exhaust thread pools.
Rate Limiting & Retries: Envoy tracks retry budgets with exponential backoff, preventing failed requests from creating a self-inflicted Thundering Herd attack on downstream databases.

Tier 3: Solving Spatial Routing with Uber H3

Layer 7 proxies solve microservice routing, but they cannot answer the fundamental question: How do you map a moving driver and passenger in physical space to the exact same server instance?

Continuous GPS coordinates are represented by floating-point numbers (e.g., 40.7580° N, 73.9855° W). You cannot performantly shard floating-point numbers across a fixed server cluster using traditional hash functions.

The Invention of Uber H3

To translate continuous geographic coordinates into discrete, hashable units, Uber developed H3—an open-source, hexagonal hierarchical spatial index.

       / \     / \
     /     \ /     \
    | (8828) | (8829)|  <-- Hexagonal H3 Cells
     \     / \     /    (Identical distances to all 6 neighbors)
       \ /     \ /

H3 overlays a mathematical grid of hexagons across the entire surface of the Earth:

Why Hexagons over Squares? Square grid systems have a critical flaw: the distance from a square's center to its edge differs from the distance to its corner. Hexagons feature equidistant centroids to all six neighboring cells. This geometric symmetry drastically simplifies radius calculations when locating nearby drivers.
Resolution Levels: H3 supports 16 resolution tiers. At Resolution 8, a city is divided into hexagonal cells roughly 700 meters wide.

Every raw GPS coordinate transforms instantly into a unique 64-bit integer H3 cell ID.

Tier 3 (Continued): Ringpop and In-Memory Stateful Sharding

Now that physical location is represented by a 64-bit integer, how does Uber map those cell IDs to servers without hitting a central database?

Uber built Ringpop, an open-source decentralized application-level routing library embedded directly into worker nodes.

Consistent Hashing on the Ring

Ringpop organizes worker nodes into a unified, distributed hash ring using consistent hashing:

$$\text{Cell ID (e.g., 8828308281FFFFF)} \xrightarrow{\quad \text{Ringpop Hash} \quad} \text{Assigned Server Node}$$

                   Node A (Owner: Cell 8828)
                       /               \
                      /                 \
            Node D                       Node B
                      \                 /
                       \               /
                   Node C (Owner: Cell 8829)

When a driver sends a GPS update or a passenger requests a ride in Manhattan (Cell 8828):

Ringpop hashes the H3 Cell ID.
The hash ring resolves to Node A.
Both the driver update and the rider request route to Node A's local RAM.

Spatial matching takes place directly in memory at microsecond speeds. There are zero disk writes and zero cross-datacenter fanout queries.

Decentralized Health Management: The SWIM Gossip Protocol

In a cluster scaling thousands of nodes, hardware failures are inevitable. Disk drives corrupt, network interfaces drop packets, and virtual machines terminate unexpected.

Traditional systems rely on a centralized coordinator like Apache ZooKeeper to manage cluster topology. However, at extreme scale, a central coordinator becomes a massive bottleneck and single point of failure.

Ringpop avoids central coordinators entirely by implementing the SWIM Gossip Protocol:

[Node A] ──(1. Ping)──> [Node B] (No Ack)
   │
   ├──(2. Indirect Ping via Node C & D)──> [Node B] (No Ack)
   │
   └──(3. Declare Dead) ──> [Gossip Update to Cluster]

Direct Ping: Node A periodically sends a lightweight ping to a random peer, Node B.
Indirect Ping: If Node B fails to respond, Node A does not immediately mark it dead. It requests two neutral peers (Node C and Node D) to ping Node B indirectly.
Decentralized Consensus: If Nodes C and D also fail to reach Node B, Node B is declared dead.
Gossip Propagation: This health state whispers across the entire cluster within seconds. The distributed hash ring automatically rebalances, assigning dead H3 cell IDs to surviving nodes.

Key System Design Lessons for Software Engineers

Uber’s load balancing evolution provides invaluable architecture lessons for building resilient, distributed software:

Layer Separation: Never mix low-level packet handling with high-level application business logic. Use Layer 4 for raw TCP throughput at the edge, and Layer 7 for protocol inspection and microservice orchestration.
Data Model Optimization: Transforming unstructured, continuous GPS data into discrete 64-bit H3 integers turned a complex, un-indexable spatial problem into a straightforward distributed hashing mechanism.
Embrace In-Memory State for Ephemeral Workloads: High-velocity write streams (like 4-second GPS updates) do not belong on persistent disks. Handle ephemeral real-time state in RAM using consistent hash rings.
Design for Decentralized Resilience: Eliminate single points of failure. Utilizing gossip protocols like SWIM allows large-scale application clusters to self-heal without centralized orchestrators.

By combining L4/L7 network decoupling with hexagonal spatial sharded memory, Uber transformed an impossibly complex real-time coordination problem into an elegant, scalable engineering system.

#webzonetechtips

#webzonezidane

How Discord Stores 11 Billion Messages (Without Melting)

Zidane — Wed, 05 Aug 2026 10:58:34 +0000

How Discord Stores 11 Billion Messages (Without Melting)

Every day, hundreds of millions of gamers, developers, and online communities send billions of chat messages on Discord. Whether it’s a simple "gg," a massive meme flood during an esports tournament, or a code snippet shared in a programming community, every single keystroke must be stored permanently, indexed instantly, and delivered across the world in milliseconds.

Back in 2017, Discord’s engineering team faced a terrifying milestone: their primary database was hitting a hard wall. They were storing over 11 billion messages, and the underlying database—Apache Cassandra—was starting to choke.

Read latencies were spiking, garbage collection freezes were causing random site-wide lags, and adding new server nodes felt like trying to put out a fire with gasoline.

This is the story of how Discord’s engineering team pulled off one of the most audacious database migrations in modern tech history: moving billions of live messages to a brand-new storage engine with zero downtime and zero dropped chats.

The Architectural Summary

If you are looking for the quick system design takeaway, here is how Discord solved their massive database bottleneck:

The Original Architecture (MongoDB to Cassandra): Discord started on MongoDB, quickly outgrew it, and migrated to Apache Cassandra for its wide-column, distributed key-value model.
The Cassandra Bottleneck: Java’s Garbage Collection (GC) pauses and unpredictable compaction cycles led to massive read-latency spikes ($100\text{ms}$ to several seconds).
The Solution (ScyllaDB): Discord migrated from Java-based Cassandra to ScyllaDB, a C++ rewrite of Cassandra that eliminates JVM garbage collection entirely and leverages thread-per-core hardware architecture.
The Custom Data Layer (Data Services): Discord built a intermediate service layer written in Rust to coalesce duplicate database requests, shielding the database from traffic surges.

1. The Early Days: MongoDB to Apache Cassandra

When Discord launched in 2015, the entire application ran on a single MongoDB replica set. MongoDB was fast to build on, but as the platform exploded in popularity, the message table outgrew the server's available RAM.

To survive, Discord needed a database that was:

Linearly Scalable: Easy to expand simply by adding more hardware nodes.
High Write Throughput: Capable of handling thousands of concurrent message writes per second.
Fault-Tolerant: Free of single points of failure.

In 2016, Discord migrated to Apache Cassandra. Cassandra is a distributed, wide-column NoSQL database designed at Facebook to handle massive write volumes across multiple server nodes.

How Discord Partitioned Data in Cassandra

To store billions of messages efficiently, Discord needed a clever database schema. They created a primary partition key based on the channel_id. Because messages in a channel are always retrieved together in chronological order, grouping messages by channel made fetching chat history incredibly fast.

+-------------------------------------------------------------------------+
|                       DISCORD CASSANDRA SCHEMA                          |
+-------------------------------------------------------------------------+
| Partition Key : channel_id (e.g., Channel #general)                    |
| Clustering Key: message_id (Snowflake ID: timestamp + worker + seq)     |
+-------------------------------------------------------------------------+
| Row 1         | Message ID: 1001 | User: Alice | Text: "Hello!"        |
| Row 2         | Message ID: 1002 | User: Bob   | Text: "Hey there!"    |
| Row 3         | Message ID: 1003 | User: Charlie| Text: "Ready to game?"|
+-------------------------------------------------------------------------+

To generate unique, chronologically sortable message IDs across distributed servers, Discord utilized Snowflake IDs (a 64-bit integer encoding a millisecond timestamp, worker process ID, and sequence number).

For years, Cassandra handled the load brilliantly. But by 2022, as the total message count skyrocketed past 100 billion, the system began to unravel.

2. The Nightmare: Java GC Pauses & Hot Partitions

Why did Apache Cassandra start struggling? The short answer comes down to Java and Disk I/O.

Problem A: The Java Virtual Machine (JVM) Garbage Collector

Apache Cassandra is written in Java. Java relies on an automatic Garbage Collector (GC) to clear unused memory. As Discord's dataset ballooned into hundreds of terabytes, Cassandra’s JVM heaps were constantly filling up with temporary query objects.

When Java’s Garbage Collector ran its deep cleaning cycle (Stop-the-World GC pauses), entire database nodes would freeze for several seconds. To the rest of the cluster, a frozen node looked like a crashed node, causing unnecessary cluster-wide panic and traffic rerouting.

Normal Operation: [ Query ] ──► [ DB Node Response (5ms) ]

During JVM GC Pause: [ Query ] ──► [ DB Node Frozen... ] ──► [ Timeout Spike (2000ms+) ]

Problem B: Tombstones and Compaction

In Cassandra, when a user deletes a message, the database doesn't instantly delete it from the disk. Instead, it writes a marker called a Tombstone.

When a user opened a channel with many deleted messages, Cassandra had to read through thousands of tombstones just to find the surviving messages. This caused massive read-latency spikes, pushing response times from a crisp $5\text{ms}$ up to several agonizing seconds.

3. The New Engine: Enter ScyllaDB

Faced with unacceptable latency spikes, Discord’s engineering team realized that tuning the Java Virtual Machine was no longer enough. They needed to replace the database engine itself.

They chose ScyllaDB.

ScyllaDB is a ground-up rewrite of Apache Cassandra written in C++. It is $100\%$ protocol-compatible with Cassandra (meaning Discord could use the exact same client drivers and query language), but its underlying performance architecture is fundamentally different.

+------------------------------------+------------------------------------+
|  APACHE CASSANDRA (JAVA)           |  SCYLLADB (C++ REWRITE)            |
+------------------------------------+------------------------------------+
| - Managed Memory (JVM GC Pauses)   | - Manual C++ Memory Management     |
| - Thread Pool Model                | - Thread-Per-Core Architecture     |
| - High CPU Overhead                | - Direct Asynchronous I/O (io_uring)|
| - Susceptible to Latency Spikes    | - Ultra-consistent Low Latency     |
+------------------------------------+------------------------------------+

The Power of Thread-per-Core

In traditional Java applications, operating system threads are constantly context-switching between different CPU cores, causing lock contention and performance bottlenecks.

ScyllaDB uses a Thread-per-Core architecture. It pins a single execution thread to each individual CPU core. Memory and network queues are partitioned so that each core operates independently without waiting for locks from other cores.

By eliminating the JVM Garbage Collector and embracing bare-metal C++ efficiency, ScyllaDB delivered predictable, sub-millisecond latencies even under brutal traffic loads.

4. The Shield: Building "Data Services" in Rust

Replacing the database engine was only half the battle. Discord’s engineers knew that even the fastest database on Earth can be knocked offline if thousands of clients query the exact same data at the same instant (a phenomenon known as the Thundering Herd Problem).

To protect ScyllaDB, Discord built an intermediate caching and request coalescing layer written in Rust, called Data Services.

[ User Requests (10,000 Concurrent Users) ]
                    │
                    ▼
       [ RUST DATA SERVICES LAYER ]
   (Coalesces 10,000 identical queries)
                    │
                    ▼  (Only 1 query sent to DB!)
         [ SCYLLADB CLUSTER ]

How Request Coalescing Works:

Imagine a popular streamer posts a message in a Discord channel with 100,000 active viewers. All 100,000 client apps will instantly send a read request for the exact same message ID at the exact same millisecond.

Instead of sending 100,000 separate queries to ScyllaDB:

The incoming requests hit the Rust Data Services layer.
The service detects that 10,000 users are asking for the exact same message_id.
It sends only ONE single query to ScyllaDB.
When ScyllaDB responds, the Data Services layer duplicates the response in memory and returns it to all 10,000 waiting users simultaneously.

This caching mechanism reduced database read traffic by orders of magnitude, smoothing out traffic spikes during viral events.

5. Live Migration: Moving Billions of Rows Zero Downtime

Migrating hundreds of billions of records while millions of users are actively chatting is like replacing the engine of a commercial jet mid-flight. Discord could not afford a maintenance window.

To pull off a seamless zero-downtime migration, they executed a Dual-Writing Engineering Strategy:

[ Incoming User Writes/Edits ]
             │
             ├───────────────┬───────────────┐
             ▼                               ▼
    [ CASSANDRA (Old DB) ]          [ SCYLLADB (New DB) ]
             │                               ▲
             │                               │
             └───► [ BACKGROUND MIGRATOR ] ──┘
                    (Copies Historical Data)

Dual Writing: Discord updated their application code to write all new messages, edits, and deletions to both Cassandra and ScyllaDB simultaneously.
Historical Backfill: They built background worker tasks to read historical messages from Cassandra and copy them over to ScyllaDB in reverse chronological order.
Consistency Verification: Automated validation scripts compared records between both databases to ensure $100\%$ data integrity.
The Cutover: Once the backfill was complete and data parity was confirmed, Discord flipped the read switch. All user traffic was instantly pointed to ScyllaDB, and the old Cassandra cluster was safely decommissioned.

Summary & Key Takeaways

Discord’s migration from Cassandra to ScyllaDB is a masterclass in modern infrastructure scaling:

How Discord Stores 11 Billion Messages (Without Melting)

Read latencies were spiking, garbage collection freezes were causing random site-wide lags, and adding new server nodes felt like trying to put out a fire with gasoline.

The TL;DR Architectural Summary

If you are looking for the quick system design takeaway, here is how Discord solved their massive database bottleneck:

The Original Architecture (MongoDB to Cassandra): Discord started on MongoDB, quickly outgrew it, and migrated to Apache Cassandra for its wide-column, distributed key-value model.
The Cassandra Bottleneck: Java’s Garbage Collection (GC) pauses and unpredictable compaction cycles led to massive read-latency spikes ($100\text{ms}$ to several seconds).
The Solution (ScyllaDB): Discord migrated from Java-based Cassandra to ScyllaDB, a C++ rewrite of Cassandra that eliminates JVM garbage collection entirely and leverages thread-per-core hardware architecture.
The Custom Data Layer (Data Services): Discord built a intermediate service layer written in Rust to coalesce duplicate database requests, shielding the database from traffic surges.

1. The Early Days: MongoDB to Apache Cassandra

To survive, Discord needed a database that was:

Linearly Scalable: Easy to expand simply by adding more hardware nodes.
High Write Throughput: Capable of handling thousands of concurrent message writes per second.
Fault-Tolerant: Free of single points of failure.

In 2016, Discord migrated to Apache Cassandra. Cassandra is a distributed, wide-column NoSQL database designed at Facebook to handle massive write volumes across multiple server nodes.

How Discord Partitioned Data in Cassandra

+-------------------------------------------------------------------------+
|                       DISCORD CASSANDRA SCHEMA                          |
+-------------------------------------------------------------------------+
| Partition Key : channel_id (e.g., Channel #general)                    |
| Clustering Key: message_id (Snowflake ID: timestamp + worker + seq)     |
+-------------------------------------------------------------------------+
| Row 1         | Message ID: 1001 | User: Alice | Text: "Hello!"        |
| Row 2         | Message ID: 1002 | User: Bob   | Text: "Hey there!"    |
| Row 3         | Message ID: 1003 | User: Charlie| Text: "Ready to game?"|
+-------------------------------------------------------------------------+

For years, Cassandra handled the load brilliantly. But by 2022, as the total message count skyrocketed past 100 billion, the system began to unravel.

2. The Nightmare: Java GC Pauses & Hot Partitions

Why did Apache Cassandra start struggling? The short answer comes down to Java and Disk I/O.

Problem A: The Java Virtual Machine (JVM) Garbage Collector

Normal Operation: [ Query ] ──► [ DB Node Response (5ms) ]

During JVM GC Pause: [ Query ] ──► [ DB Node Frozen... ] ──► [ Timeout Spike (2000ms+) ]

Problem B: Tombstones and Compaction

In Cassandra, when a user deletes a message, the database doesn't instantly delete it from the disk. Instead, it writes a marker called a Tombstone.

3. The New Engine: Enter ScyllaDB

Faced with unacceptable latency spikes, Discord’s engineering team realized that tuning the Java Virtual Machine was no longer enough. They needed to replace the database engine itself.

They chose ScyllaDB.

+------------------------------------+------------------------------------+
|  APACHE CASSANDRA (JAVA)           |  SCYLLADB (C++ REWRITE)            |
+------------------------------------+------------------------------------+
| - Managed Memory (JVM GC Pauses)   | - Manual C++ Memory Management     |
| - Thread Pool Model                | - Thread-Per-Core Architecture     |
| - High CPU Overhead                | - Direct Asynchronous I/O (io_uring)|
| - Susceptible to Latency Spikes    | - Ultra-consistent Low Latency     |
+------------------------------------+------------------------------------+

The Power of Thread-per-Core

In traditional Java applications, operating system threads are constantly context-switching between different CPU cores, causing lock contention and performance bottlenecks.

By eliminating the JVM Garbage Collector and embracing bare-metal C++ efficiency, ScyllaDB delivered predictable, sub-millisecond latencies even under brutal traffic loads.

4. The Shield: Building "Data Services" in Rust

To protect ScyllaDB, Discord built an intermediate caching and request coalescing layer written in Rust, called Data Services.

[ User Requests (10,000 Concurrent Users) ]
                    │
                    ▼
       [ RUST DATA SERVICES LAYER ]
   (Coalesces 10,000 identical queries)
                    │
                    ▼  (Only 1 query sent to DB!)
         [ SCYLLADB CLUSTER ]

How Request Coalescing Works:

Instead of sending 100,000 separate queries to ScyllaDB:

The incoming requests hit the Rust Data Services layer.
The service detects that 10,000 users are asking for the exact same message_id.
It sends only ONE single query to ScyllaDB.
When ScyllaDB responds, the Data Services layer duplicates the response in memory and returns it to all 10,000 waiting users simultaneously.

This caching mechanism reduced database read traffic by orders of magnitude, smoothing out traffic spikes during viral events.

5. Live Migration: Moving Billions of Rows Zero Downtime

Migrating hundreds of billions of records while millions of users are actively chatting is like replacing the engine of a commercial jet mid-flight. Discord could not afford a maintenance window.

To pull off a seamless zero-downtime migration, they executed a Dual-Writing Engineering Strategy:

[ Incoming User Writes/Edits ]
             │
             ├───────────────┬───────────────┐
             ▼                               ▼
    [ CASSANDRA (Old DB) ]          [ SCYLLADB (New DB) ]
             │                               ▲
             │                               │
             └───► [ BACKGROUND MIGRATOR ] ──┘
                    (Copies Historical Data)

Dual Writing: Discord updated their application code to write all new messages, edits, and deletions to both Cassandra and ScyllaDB simultaneously.
Historical Backfill: They built background worker tasks to read historical messages from Cassandra and copy them over to ScyllaDB in reverse chronological order.
Consistency Verification: Automated validation scripts compared records between both databases to ensure $100\%$ data integrity.
The Cutover: Once the backfill was complete and data parity was confirmed, Discord flipped the read switch. All user traffic was instantly pointed to ScyllaDB, and the old Cassandra cluster was safely decommissioned.

Summary & Key Takeaways

Discord’s migration from Cassandra to ScyllaDB is a masterclass in modern infrastructure scaling:

Architecture Era	Database Used	Primary Bottleneck	Performance Result
2015 (Launch)	MongoDB	Outgrew RAM limits on single replica set.	Unstable under rapid user growth.
2016 - 2022	Apache Cassandra	JVM Garbage Collection freezes & Tombstones.	Spikes up to $2000\text{ms}+$ read latency.
2023 - Present	ScyllaDB + Rust Data Services	Managed via C++ bare-metal efficiency & request coalescing.	Sub-millisecond latencies ($<5\text{ms}$) at $100\text{B}+$ messages.

By replacing Java GC pauses with C++ hardware efficiency and shielding their database with a smart Rust middleware layer, Discord transformed a lagging infrastructure into a lightning-fast messaging platform capable of scaling effortlessly for years to come.

The Hidden Traffic Cop Keeping the Internet From Melting

Zidane — Sun, 02 Aug 2026 09:51:35 +0000

🚦 What is Load Balancing?

Think of a Load Balancer as a digital traffic cop sitting in front of your servers. When thousands of users visit your website at the same time, the load balancer distributes incoming web traffic across multiple backend servers so that no single server gets overwhelmed, crashes, or slows down.

Core Benefits of Load Balancing

Zero Downtime (High Availability): If Server A crashes, the load balancer automatically redirects traffic to Server B without the user noticing.
Scalability: You can easily add 5 more servers during peak sales hours and remove them when traffic drops.
Faster Response Times: Traffic is routed to the healthiest, least busy, or geographically closest server.

🔄 The 5 Core Routing Algorithms Compared

Algorithm	How it Works (Analogy)	Best Used For
1. Round Robin	Takes turns in order: Server 1 $\rightarrow$ Server 2 $\rightarrow$ Server 3 $\rightarrow$ Server 1.	Servers with identical hardware handling short, equal requests.
2. Least Connections	Sends traffic to the server with the fewest active connections.	Long-lived connections (e.g., chat apps, streaming, gaming).
3. IP Hash	Uses the user's IP address to map them to the exact same server every time.	Applications requiring persistent user sessions (e.g., shopping carts).
4. Least Response Time	Sends traffic to the server with the fastest response time and fewest connections.	Systems where server performance fluctuates or is latency-sensitive.
5. Weighted (Bonus)	Assigns a higher capacity ratio (e.g., 3:1) to stronger servers.	Mixed infrastructure where some servers have more RAM/CPU than others.

🛠️ Deep Dive: When, Where & Why to Use Each

1. Round Robin

How it works: Imagine a dealer passing out cards around a table one by one in a circle. It cycles through servers sequentially regardless of how busy they are.
Benefits: Extremely simple to configure, virtually zero CPU overhead on the load balancer.
When to use: When all backend servers have identical CPU/RAM specs and the incoming requests take roughly the same amount of time to process (e.g., serving static HTML/CSS files).
When NOT to use: If some requests take 10 seconds (like rendering a PDF) and others take 10 milliseconds.

2. Least Connections

How it works: The load balancer keeps track of how many active open connections each server currently holds, and sends the next user to whoever has the shortest line.
Benefits: Prevents server overload when request processing times vary wildly.
When to use: Applications with long-lived connections or variable task lengths—such as live chat apps (WebSockets), file uploads, video streaming, or heavy database query rendering.

3. IP Hash

How it works: The load balancer takes the user’s IP address (e.g., 192.168.1.50), runs it through a hash function, and converts it into a number that permanently points to Server A.
Benefits: Guarantees "session stickiness" (the user always lands on the same server) without relying on browser cookies.
When to use: Legacy applications where user session state is stored in server memory (like an active shopping cart or login session) instead of a shared database like Redis.

4. Least Response Time (or Least Latency)

How it works: The load balancer constantly monitors the health and TTFB (Time To First Byte) latency of each server. It combines the fewest active connections with the fastest ping time.
Benefits: Maximizes end-user speed and automatically routes around servers that are lagging or undergoing background tasks (like memory garbage collection).
When to use: Ultra low-latency systems like high-frequency trading platforms, real-time gaming backends, or globally distributed microservices where network delays vary.

🎯 Summary Quick-Decision Guide

                          Do your servers have equal specs?

                                   │

                 ┌─────────────────┴─────────────────┐

                 YES                                 NO

                 │                                   │

      Are requests equal in length?            Use WEIGHTED 

         ┌───────┴───────┐                    ROUND ROBIN

        YES              NO

         │               │

  ROUND ROBIN     LEAST CONNECTIONS

                         │

        Need persistent session per user?

                 ┌───────┴───────┐

                YES              NO

                 │               │

              IP HASH    LEAST RESPONSE TIME

DEV Community: Zidane

What ACTUALLY Happens When You Type a URL google.com

What ACTUALLY Happens When You Type a URL google.com

⏱️ CHAPTER 1: Hardware Interrupts & OS Kernel Space

⏱️ CHAPTER 2: The Deep-Dive DNS Resolution Chain

⏱️ CHAPTER 3: Packet Assembly & MAC Address Resolution

⏱️ CHAPTER 4: BGP Routing, TCP Handshake & TLS 1.3

⏱️ CHAPTER 5: Edge Reverse Proxies & Browser Rendering

⏱️ CHAPTER 6: Conclusion & Senior Mindset

Inside Facebook's News Feed Architecture

Inside Facebook's News Feed Architecture

Chapter 1: The Scale & SLA Challenge

Chapter 2: Graph Data Modeling with TAO

Chapter 3: The Fan-Out Dilemma & Hybrid Architecture

Chapter 4: Multi-Tier Caching Infrastructure

Chapter 5: The 4-Stage AI Ranking Engine

Chapter 6: Real-Time Event Streaming & Invalidation

Chapter 7: Client-Side Optimization & GraphQL

Chapter 8: Conclusion & Key System Design Takeaways

How Uber Handles 50,000 Requests per Second Without Crashing: A System Design Deep Dive

How Uber Handles 50,000 Requests per Second Without Crashing: A System Design Deep Dive

The Illusion of Traditional Load Balancing

Why Stateless Round-Robin Fails for Ride-Hailing

The Three-Tier Architecture Overview

Tier 1: High-Speed Perimeter Routing at Layer 4

Why Layer 4 First?

Tier 2: Intelligent Microservice Gateway with Envoy Proxy

Resiliency Patterns: Circuit Breaking & Shedding

Tier 3: Solving Spatial Routing with Uber H3

The Invention of Uber H3

Tier 3 (Continued): Ringpop and In-Memory Stateful Sharding

Consistent Hashing on the Ring

Decentralized Health Management: The SWIM Gossip Protocol

Key System Design Lessons for Software Engineers

How Discord Stores 11 Billion Messages (Without Melting)

How Discord Stores 11 Billion Messages (Without Melting)

The Architectural Summary

1. The Early Days: MongoDB to Apache Cassandra

How Discord Partitioned Data in Cassandra

2. The Nightmare: Java GC Pauses & Hot Partitions

Problem A: The Java Virtual Machine (JVM) Garbage Collector

Problem B: Tombstones and Compaction

3. The New Engine: Enter ScyllaDB

The Power of Thread-per-Core

4. The Shield: Building "Data Services" in Rust

How Request Coalescing Works:

5. Live Migration: Moving Billions of Rows Zero Downtime

Summary & Key Takeaways

How Discord Stores 11 Billion Messages (Without Melting)

The TL;DR Architectural Summary

1. The Early Days: MongoDB to Apache Cassandra

How Discord Partitioned Data in Cassandra

2. The Nightmare: Java GC Pauses & Hot Partitions

Problem A: The Java Virtual Machine (JVM) Garbage Collector

Problem B: Tombstones and Compaction

3. The New Engine: Enter ScyllaDB

The Power of Thread-per-Core

4. The Shield: Building "Data Services" in Rust

How Request Coalescing Works:

5. Live Migration: Moving Billions of Rows Zero Downtime

Summary & Key Takeaways

The Hidden Traffic Cop Keeping the Internet From Melting

🚦 What is Load Balancing?

Core Benefits of Load Balancing

🔄 The 5 Core Routing Algorithms Compared

🛠️ Deep Dive: When, Where & Why to Use Each

1. Round Robin

2. Least Connections

3. IP Hash

4. Least Response Time (or Least Latency)

🎯 Summary Quick-Decision Guide

webzonetechtips

loadbalancing