DEV Community: Billy Okeyo

Client-Side Rendering vs Server-Side Rendering Explained: Where Should Your UI Be Built?

Billy Okeyo — Fri, 28 Aug 2026 00:00:00 +0000

“Every web application eventually becomes HTML in the browser. The interesting question is where that HTML should be created.”

Open two modern websites in your browser. They may look almost identical: both have navigation bars, product cards, forms, dashboards, buttons, and interactive components, and both may even be built using React. But underneath, the journey those interfaces took before appearing on your screen could be completely different.

One application might send the browser a relatively small HTML document:

<div id="root"></div>

<script src="https://billyokeyo.dev/app.js"></script>

JavaScript downloads, executes, fetches data, builds the interface, and inserts it into the page.

Another application might send this immediately:

<main>
    <h1>Products</h1>

    <article>
        <h2>MacBook Pro</h2>
        <p>KES 250,000</p>
    </article>
</main>

The browser already has meaningful content before the application’s JavaScript finishes loading.

The first approach is broadly known as Client-Side Rendering (CSR), and the second is Server-Side Rendering (SSR).

At first, the difference sounds simple:

CSR

Server
  │
  ▼
JavaScript
  │
  ▼
Browser builds UI

versus:

SSR

Server builds UI
  │
  ▼
HTML
  │
  ▼
Browser displays UI

But that small architectural decision affects much more than where some HTML is generated.

It influences:

Initial page load
JavaScript requirements
SEO
Caching
Server infrastructure
Time to interactive
Data fetching
Navigation
Personalization
Failure modes
Application complexity

And modern frameworks have made the distinction even more interesting. Next.js can render some things on the server and others in the browser, Nuxt does something similar for Vue, and Astro can ship almost no JavaScript for parts of a page while hydrating interactive islands. Modern applications increasingly aren’t purely client-rendered or purely server-rendered.

To understand why, we first need to understand what actually happens in each model.

What Is Client-Side Rendering?

In Client-Side Rendering, the browser receives enough HTML to bootstrap the application, but JavaScript performs much of the work required to construct the actual interface.

A simplified React application might start with:

<!DOCTYPE html>
<html>
<head>
    <title>Store</title>
</head>
<body>

    <div id="root"></div>

    <script src="https://billyokeyo.dev/app.js"></script>

</body>
</html>

Notice what’s missing: there are no products, there is no navigation, and there may not even be a visible heading. Instead, the browser downloads app.js, and React then mounts the application.

const root = ReactDOM.createRoot(
    document.getElementById("root")
);

root.render(<App />);

The application may then fetch data.

fetch("/api/products")
    .then(response => response.json())
    .then(products => {
        // Update application state
    });

Eventually, React creates the DOM necessary to display the page.

Conceptually:

Request Page
     │
     ▼
Server
     │
     ▼
Minimal HTML
     │
     ▼
Browser
     │
     ▼
Download JavaScript
     │
     ▼
Parse JavaScript
     │
     ▼
Execute Application
     │
     ▼
Fetch Data
     │
     ▼
Build DOM
     │
     ▼
Render UI

The browser does a significant amount of work before the user sees the completed application. That’s Client-Side Rendering.

Why Client-Side Rendering Became Popular

Traditional websites worked differently. Clicking a link usually caused the browser to request another document from the server.

Page A
  │
  │ Click link
  ▼
Server Request
  │
  ▼
New HTML Document
  │
  ▼
Page B

The browser navigated away from the current page and loaded another.

This model worked extremely well, and it still does.

But as web applications became increasingly interactive, developers wanted experiences that behaved more like desktop applications. Instead of requesting an entirely new page whenever something changed, JavaScript could update only the necessary parts of the interface.

This led to the rise of Single-Page Applications, or SPAs. Frameworks such as Angular, React, and Vue made these applications much easier to build, and navigation could happen without a full page reload.

Initial Page
     │
     ▼
JavaScript Application
     │
     ├────► /products
     │
     ├────► /orders
     │
     └────► /profile

The application remained loaded while the UI changed around it.

For dashboards, admin portals, project management tools, email clients, and other highly interactive applications, this was extremely attractive.

The Client-Side Rendering Experience

Imagine visiting an online store implemented entirely using CSR.

The browser requests:

GET /products

The server might respond with:

<!DOCTYPE html>
<html>
<body>

    <div id="root"></div>

    <script src="https://billyokeyo.dev/bundle.js"></script>

</body>
</html>

The browser can parse this almost immediately, but there still isn’t much useful content.

Download bundle.js

Perhaps that bundle is:

300 KB

or:

1 MB

or considerably larger.

Downloading isn’t the end of the work.

JavaScript must also be:

Downloaded
    │
    ▼
Parsed
    │
    ▼
Compiled
    │
    ▼
Executed

Then the application starts and may immediately request:

GET /api/products

Only after that response arrives can the application render the product list.

HTML
 │
 ▼
JavaScript
 │
 ▼
API Request
 │
 ▼
Data
 │
 ▼
UI

This creates what is sometimes called a request waterfall: the user requested the page long ago, but useful content depended on several sequential steps.

The Empty Page Problem

This is one of the classic weaknesses of pure CSR.

Suppose your initial HTML contains:

<div id="root">
    <div class="spinner"></div>
</div>

The browser can render something, but the actual content isn’t available yet.

On a fast laptop with fiber internet, this might happen so quickly that nobody notices.

Now imagine:

Budget Android phone
        +
Slow mobile network
        +
Large JavaScript bundle
        +
Slow API response

The experience changes considerably.

User opens page
      │
      ▼
Blank / Loading UI
      │
      │
      │
      ▼
JavaScript loads
      │
      ▼
Application starts
      │
      ▼
Data loads
      │
      ▼
Content appears

This doesn’t mean CSR is inherently slow. A well-built client-rendered application can be extremely fast, but it does mean the browser may have more work to perform before meaningful content appears.

What Is Server-Side Rendering?

Server-Side Rendering moves some of that work away from the browser. Instead of sending an almost empty application shell, the server generates HTML for the requested page.

Suppose the user requests:

GET /products

The server loads the necessary data.

Server
  │
  ▼
Database / API
  │
  ▼
Products

It then renders the page. The browser receives:

<main>
    <h1>Products</h1>

    <article>
        <h2>Laptop</h2>
        <p>KES 75,000</p>
    </article>

    <article>
        <h2>Monitor</h2>
        <p>KES 35,000</p>
    </article>
</main>

The journey becomes:

Request
   │
   ▼
Server
   │
   ├── Fetch data
   │
   └── Render HTML
   │
   ▼
HTML Response
   │
   ▼
Browser
   │
   ▼
Content

The browser receives meaningful HTML from the beginning. That’s Server-Side Rendering.

A Simple Server-Side Example

Imagine an Express application using a template engine.

app.get("/products", async (req, res) => {
    const products = await productService.getAll();

    res.render("products", {
        products
    });
});

The template might contain:

<h1>Products</h1>

<% products.forEach(product => { %>

    <article>
        <h2><%= product.name %></h2>
        <p><%= product.price %></p>
    </article>

<% }) %>

The browser doesn’t need JavaScript to create those product elements because the server already did it.

This model isn’t new. PHP, Ruby on Rails, Django, Laravel, ASP.NET MVC, JSP, and countless other technologies have rendered HTML on servers for decades. What changed is that modern frontend frameworks started bringing server rendering back into JavaScript-heavy application architectures.

CSR vs SSR: The Fundamental Difference

At its simplest:

CLIENT-SIDE RENDERING

Server
  │
  ▼
Application Shell
  │
  ▼
Browser
  │
  ├── Load JavaScript
  ├── Execute Application
  ├── Fetch Data
  └── Build UI

While:

SERVER-SIDE RENDERING

Browser
  │
  ▼
Server
  │
  ├── Fetch Data
  └── Build HTML
  │
  ▼
Browser receives UI

The final browser DOM may look almost identical, but the difference is where the initial work happened.

But Server-Rendered HTML Isn’t Necessarily Interactive

Suppose the server sends:

<button id="cart">
    Add to Cart
</button>

The browser can display the button immediately, but what happens when the user clicks it?

If the page is supposed to behave like an interactive React application, the browser still needs JavaScript. This introduces another important concept: Hydration.

A server-rendered React application might conceptually work like this:

Server
  │
  ▼
Render React Components
  │
  ▼
HTML
  │
  ▼
Browser Displays Page
  │
  ▼
JavaScript Downloads
  │
  ▼
React Hydrates HTML
  │
  ▼
Page Becomes Fully Interactive

Before hydration:

Looks like application

After hydration:

Behaves like application

This distinction creates an interesting performance problem. A user may be able to see a button before the JavaScript necessary to handle that button has finished loading and executing. The page looks ready, but it isn’t necessarily ready.

We’ll explore hydration deeply in the next article. For now, remember:

SSR can make content visible earlier, but interactive applications may still require significant client-side JavaScript.

Initial Load Performance

This is where CSR and SSR are often compared most aggressively. Imagine a CSR application:

Request
  │
  ▼
HTML
  │
  ▼
JavaScript
  │
  ▼
Execute
  │
  ▼
Fetch Data
  │
  ▼
Render

Now SSR:

Request
  │
  ▼
Server Fetches Data
  │
  ▼
Server Renders
  │
  ▼
HTML
  │
  ▼
Browser Renders

SSR can often deliver meaningful content earlier because the browser doesn’t have to wait for the application to construct that content, but that doesn’t automatically mean SSR is faster in every situation. The server now has work to do before sending the response.

If server rendering requires slow database queries:

Request
  │
  ▼
Database
  │
  │ 1.5 seconds
  ▼
Render
  │
  ▼
Response

the browser may wait longer for the initial HTML.

Performance depends on the entire system.

Time to First Byte vs Useful Content

SSR can introduce an interesting trade-off. With CSR, the server can often return the initial shell quickly:

Request
  │
  ▼
HTML shell

That can produce a fast Time to First Byte, but meaningful content may arrive later.

SSR may take longer before sending the first HTML because the server needs to fetch data and render the page.

Request
  │
  ▼
Fetch Data
  │
  ▼
Render
  │
  ▼
HTML

But when the response arrives, it already contains useful content. So asking whether one approach returns HTML faster isn’t enough. A better question is:

“When can the user actually see and use the content they came for?”

SEO and Crawlers

SEO is one of the most frequently cited reasons for SSR.

Imagine a crawler receives:

<div id="root"></div>

<script src="https://billyokeyo.dev/app.js"></script>

The meaningful content depends on JavaScript execution. Modern search engines have become much better at processing JavaScript, but server-rendered HTML still provides a simpler and more predictable document for crawlers, link previews, social platforms, and other systems that consume webpage metadata.

Compare:

<div id="root"></div>

with:

<article>
    <h1>
        The Browser Rendering Pipeline Explained
    </h1>

    <p>
        Learn how browsers turn HTML into pixels...
    </p>
</article>

The second document already describes the content without requiring application execution.

For:

Blogs
Documentation
News websites
E-commerce product pages
Marketing websites
Public landing pages

having content available in the initial HTML is often valuable.

For:

Internal accounting dashboard

SEO probably doesn’t matter at all. Architecture should follow requirements.

CSR Can Be Excellent for Application-Like Interfaces

Imagine you’re building an internal analytics dashboard. Users authenticate once, then spend hours navigating between:

Overview
Reports
Customers
Invoices
Settings

SEO is irrelevant, the application is highly interactive, and users frequently move between screens.

A client-rendered SPA can work extremely well. After the initial JavaScript has loaded, navigation may require only data requests.

Application already loaded
        │
        ├── /api/reports
        ├── /api/customers
        └── /api/invoices

The shell remains in the browser, and only data and necessary UI updates change.

This can create a very responsive application experience. The point isn’t that CSR is outdated; it’s that different applications have different performance profiles.

SSR Has a Server Cost

With CSR, your backend might primarily serve static assets and APIs, and a CDN can distribute:

index.html
app.js
styles.css

very efficiently.

With dynamic SSR, each page request may require server computation.

Request 1 ─────► Render Page

Request 2 ─────► Render Page

Request 3 ─────► Render Page

Request 4 ─────► Render Page

At scale:

Thousands of requests
        │
        ▼
Server Rendering
        │
        ▼
CPU + Memory + Data Access

Now you need to think about:

Server capacity
Rendering latency
Caching
Database load
Failure handling
Geographic distribution

SSR moves work away from the client, but it doesn’t make the work disappear. It moves responsibility to another part of the system.

Static Site Generation Enters the Picture

What if the page doesn’t change on every request? Suppose you’re publishing a technical article. Rendering it on the server every single time someone visits may be unnecessary, so instead, the HTML can be generated during deployment. This is commonly known as Static Site Generation, or SSG.

BUILD TIME

Markdown
   │
   ▼
Framework
   │
   ▼
Generate HTML
   │
   ▼
Static File

Then at request time:

User
 │
 ▼
CDN
 │
 ▼
Pre-generated HTML

No application server needs to render the article for every visitor, which can be extremely fast and highly cacheable.

CSR vs SSR vs SSG

We now have three broad models.

Client-Side Rendering

Request Time

Server
  │
  ▼
Application Shell
  │
  ▼
Browser builds UI

Server-Side Rendering

Request Time

Request
  │
  ▼
Server builds UI
  │
  ▼
HTML

Static Site Generation

Build Time

Framework
  │
  ▼
HTML generated ahead of time

Request Time

CDN
  │
  ▼
HTML

A simplified comparison:

Characteristic	CSR	SSR	SSG
Initial HTML content	Limited in pure CSR	Rich	Rich
Rendering happens	Browser	Server	Build time
SEO friendliness	Depends on implementation	Strong	Strong
Server work per request	Low	Potentially higher	Very low
Dynamic personalization	Strong	Strong	Limited without client/server additions
CDN caching	Excellent for shell/assets	Possible but more complex	Excellent
Highly interactive apps	Excellent	Excellent after client JS	Requires client JS for interaction
Content-heavy sites	Possible	Strong	Excellent when content changes infrequently

But modern frameworks don’t force you to choose one strategy for your entire application, and that’s where things get more interesting.

Modern Applications Are Hybrid

Imagine an e-commerce application. Its homepage contains marketing content that changes once per day, its product pages change when inventory or prices change, its shopping cart is specific to each user, and its account dashboard requires authentication and real-time information.

Why should all four parts use exactly the same rendering strategy? They probably shouldn’t.

A modern architecture might look like:

Homepage
   │
   └── Static Generation

Product Page
   │
   └── Server Rendering / Cached Rendering

Shopping Cart
   │
   └── Client Interaction

Account Dashboard
   │
   └── Server + Client

Instead of asking:

CSR or SSR?

modern frontend architecture increasingly asks:

Which parts should run where?

Next.js and Hybrid Rendering

This is one reason frameworks such as Next.js became popular: a single application can combine multiple rendering strategies.

Conceptually:

Next.js Application
        │
        ├── Static pages
        │
        ├── Server-rendered pages
        │
        ├── Server components
        │
        └── Client components

A mostly static marketing page doesn’t need the same architecture as an interactive dashboard. Modern frameworks allow developers to make those decisions at a much smaller granularity, and the boundary between “frontend” and “backend” becomes less rigid.

Server Components Add Another Dimension

Traditional SSR generally works like:

Server
  │
  ▼
HTML
  │
  ▼
Browser
  │
  ▼
Hydrate JavaScript

Server Components introduce a different idea: some components execute only on the server and don’t need their component JavaScript shipped to the browser.

Conceptually:

Page
│
├── ProductDetails
│      Server
│
├── Reviews
│      Server
│
└── AddToCartButton
       Client

The interactive button needs browser JavaScript, but the static product description may not.

That means instead of sending JavaScript for everything:

Browser

ProductDetails JS
Reviews JS
Button JS
Navigation JS
Footer JS

you can potentially send client-side JavaScript only where interaction requires it.

Browser

Button JS
Navigation JS

This is another example of the industry moving away from the idea that an entire application must belong exclusively to either the client or the server.

The JavaScript Cost Still Matters

In the previous article, we explored the JavaScript event loop and why long-running JavaScript can freeze the UI, and that knowledge matters here.

Suppose SSR delivers content almost instantly. Great. But then the browser downloads:

2.5 MB JavaScript

and spends significant time parsing and executing it.

The user may see the page quickly but still struggle to interact with it.

HTML arrives
     │
     ▼
Content visible
     │
     ▼
Large JS bundle
     │
     ▼
Parse + Execute
     │
     ▼
Hydration
     │
     ▼
Interactive

This is why SSR isn’t a magical performance switch. You need to think about both:

How quickly can users SEE the page?

and

How quickly can users USE the page?

Those are related but different questions.

Data Fetching Changes Too

CSR often produces a pattern like:

Browser
   │
   ▼
Load Application
   │
   ▼
Application Starts
   │
   ▼
Fetch /api/user
   │
   ▼
Fetch /api/orders
   │
   ▼
Render

With server rendering, data can often be fetched before HTML is sent.

Browser
   │
   ▼
Server
   │
   ├── Fetch User
   ├── Fetch Orders
   │
   ▼
Render HTML
   │
   ▼
Browser

This can eliminate some client-side waterfalls and can also allow the server to access internal services or databases without exposing those credentials or endpoints directly to the browser.

But now server rendering depends on those services, and if one is slow, the page may become slow. Again, architecture moves trade-offs around; it rarely eliminates them.

Caching Changes the Equation

Suppose 100,000 people request the same product page. If you dynamically server-render the page 100,000 times:

100,000 Requests
       │
       ▼
100,000 Renders

that could be wasteful.

If the response can safely be cached:

First Request
     │
     ▼
Render
     │
     ▼
Cache
     │
     ├────► User
     ├────► User
     ├────► User
     └────► User

the economics change dramatically.

Caching can make server-generated content behave much more like static content from an infrastructure perspective, which is why rendering strategy and caching strategy should often be designed together.

Personalized Pages Are Different

Now imagine:

/dashboard

Billy sees:

Welcome Billy

Account Balance: ...
Recent Orders: ...

Alice sees completely different data.

Caching the entire HTML response globally is dangerous because responses are user-specific.

You now need to consider:

Authentication
Personalization
Cache boundaries
Data privacy
Server rendering cost

This doesn’t mean SSR is wrong. It means personalized SSR has a different operational profile from rendering a public blog article.

Failure Modes Are Different

Suppose a pure CSR application loads successfully but its API fails. The browser may still have the application shell.

Application
    │
    ▼
API fails
    │
    ▼
Show error state

With SSR, if the server cannot obtain critical data, it may be unable to generate the page.

Request
   │
   ▼
Server
   │
   ▼
Data dependency fails
   │
   ▼
Page rendering fails

You therefore need to think about:

Timeouts
Partial rendering
Error boundaries
Fallback content
Retries
Caching stale data
Graceful degradation

Rendering architecture isn’t only a performance decision; it’s also a reliability decision.

Another common misconception is:

SSR means every click reloads the entire page.

That doesn’t have to be true. Modern SSR frameworks frequently combine server-rendered initial requests with client-side navigation.

The first request might look like:

Browser
   │
   ▼
Server
   │
   ▼
Rendered Page

Then subsequent navigation can behave more like:

Current Application
      │
      ▼
Click /products/42
      │
      ▼
Fetch required data/content
      │
      ▼
Update interface

This hybrid behavior allows applications to combine fast initial content with smooth navigation, and again, the boundary is becoming less binary.

When Should You Choose CSR?

CSR remains an excellent choice when the application is primarily an interactive tool rather than publicly indexed content.

Examples include:

Admin dashboards
Internal business tools
Analytics platforms
Complex editors
Authenticated SaaS applications
Project management tools
Email-like applications

CSR can be particularly attractive when users remain inside the application for long sessions, since the initial loading cost is paid once and navigation and interactions can then happen entirely within the application shell.

You should still care about bundle size, rendering performance, caching, and code splitting, but SSR isn’t automatically necessary simply because it exists.

When Should You Choose SSR?

SSR becomes particularly attractive when initial content matters immediately.

Examples include:

E-commerce product pages
News websites
Public profiles
Search result pages
Content platforms
Pages requiring request-time personalization

It can help when:

Content needs to be available in the initial HTML.
SEO is important.
Social previews matter.
Initial rendering shouldn’t depend entirely on client JavaScript.
Data must be fresh at request time.
Server-side access to data simplifies the architecture.

But SSR comes with server complexity and shouldn’t be adopted merely because a framework makes it easy.

When Should You Choose SSG?

Static generation is extremely powerful when content doesn’t need to be regenerated for every request.

Examples include:

Blogs
Documentation
Marketing pages
Portfolios
Product documentation
Company websites

The generated HTML can be distributed through a CDN.

                 ┌── London
                 │
Origin ─── CDN ──┼── Nairobi
                 │
                 ├── New York
                 │
                 └── Singapore

Users receive files from infrastructure close to them without requiring dynamic rendering for every request. For content that changes relatively infrequently, it’s difficult to beat the simplicity and performance characteristics of static HTML.

The Wrong Question: “Which Is Faster?”

Developers often ask:

Is CSR or SSR faster?

That’s too broad. Consider two applications.

Application A

CSR dashboard:

Small bundle
Fast API
Good caching
Code splitting
Long authenticated sessions

Application B

SSR website:

Slow server
Slow database
No caching
Huge hydration bundle

Application A may easily provide the better experience. Now reverse the conditions: a massive client-rendered marketing website might perform poorly compared with a mostly static or server-rendered equivalent. Rendering strategy doesn’t determine performance by itself; implementation matters.

A Better Decision Framework

Instead of asking:

CSR or SSR?

Ask a series of smaller questions.

Does the content need SEO?

If yes, delivering meaningful HTML directly is often useful.

Is the page highly personalized?

Dynamic server rendering or client-side fetching may make sense depending on the data.

Does the content change frequently?

If not, static generation may be sufficient.

Is the application highly interactive?

Client-side JavaScript will likely play a significant role regardless of how the initial HTML is produced.

Is the page mostly content?

Avoid shipping a large JavaScript application if simple HTML can solve the problem.

Can the output be cached?

If yes, SSR or static generation can become significantly cheaper.

Does the user stay in the application for a long time?

Paying an initial CSR cost may be perfectly reasonable for a long-lived application session.

Architecture should emerge from these answers.

Common Mistake: SSR Everything

Once developers discover SSR, it’s tempting to move everything to the server, but that’s not always an improvement.

Imagine an internal drag-and-drop project management application.

It has:

Real-time updates
Rich client state
Dragging
Filtering
Modals
Optimistic updates
Keyboard shortcuts

Trying to make every interaction server-driven could introduce unnecessary network latency and complexity.

Some things belong naturally in the browser. The browser isn’t merely a dumb HTML viewer anymore; it’s an extremely capable application runtime. Use it where it makes sense.

Common Mistake: CSR Everything

The opposite extreme created many of the problems that caused SSR to regain popularity. A simple marketing page doesn’t necessarily need:

React
+
Router
+
State Library
+
API Layer
+
500 KB JavaScript

just to display:

Company Name
Product Description
Pricing
Contact Form

Sometimes HTML is enough. One of the signs of frontend engineering maturity is understanding that more JavaScript isn’t automatically more modern.

Common Mistake: Choosing Based on Framework Hype

A framework may strongly encourage a particular rendering model, but that doesn’t mean every application requires it.

Technology discussions often become:

"SSR is the future."

"SPAs are dead."

"Everything should be server components."

"Everything should be static."

Software architecture rarely works in absolutes, and every rendering strategy optimizes for different constraints.

A better engineering question is:

What does this particular page need?

Not even:

What does this application need?

Different pages inside the same application may deserve different answers.

A Practical Architecture

Imagine we’re building an online learning platform. It contains:

Homepage
Courses
Course Details
Student Dashboard
Interactive Code Editor
Documentation

We don’t need one rendering strategy.

We might choose:

Homepage
   │
   └── Static

Documentation
   │
   └── Static

Course Details
   │
   └── Server Rendered / Cached

Student Dashboard
   │
   └── Server + Client

Code Editor
   │
   └── Heavily Client-Side

Now the architecture follows the product instead of forcing the product into one architectural philosophy, and that’s increasingly what modern frontend engineering looks like.

CSR and SSR Are Not Opponents

It’s easy to discuss these approaches as if they’re competing technologies.

CSR

     VS.

SSR

But modern applications often look more like:

                    Application
                         │
          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼
       Static          Server         Client
       Content        Rendering     Interaction
          │              │              │
          └──────────────┼──────────────┘
                         │
                         ▼
                    User Experience

The server can produce the initial document, the browser can take over interaction, and some components can remain server-only while others execute entirely on the client. Some pages can be generated days before anyone requests them, while others are generated for each request.

The question is no longer:

Where does my frontend run?

Increasingly, the answer is:

Wherever each piece makes the most sense.

Bringing It All Together

Client-Side Rendering and Server-Side Rendering solve the same fundamental problem differently. Both ultimately need to produce something the browser can display.

CSR says:

Send the application to the browser
and let the browser construct the UI.

SSR says:

Construct the initial UI on the server
and send the browser meaningful HTML.

SSG goes one step further:

Construct the UI before the user
even requests it.

And modern hybrid frameworks say:

Why choose only one?

The trade-offs can be summarized like this:

                 WHERE IS THE UI CREATED?

Build Time             Server               Browser
    │                    │                     │
    ▼                    ▼                     ▼
   SSG                   SSR                   CSR

Fast static        Fresh request-time      Rich client-side
delivery           HTML                    applications

None is universally correct. The right choice depends on:

Content
Performance
Interactivity
SEO
Personalization
Caching
Infrastructure
User experience

Understanding those trade-offs is far more valuable than memorizing which rendering strategy is currently fashionable.

Final Thoughts

Frontend development spent years moving more work into the browser, then the industry rediscovered the advantages of moving some of that work back to the server. That can make it look as though we’ve gone in a circle, but we haven’t.

What changed is that we now have much finer control over where different parts of an application execute. We can generate a blog post at build time, render a personalized account page on the server, run an interactive editor in the browser, cache a product page at the edge, and combine all of those approaches inside the same product.

The most useful lesson isn’t that SSR is better than CSR, or that CSR is simpler than SSR. It’s this:

Rendering is an architectural decision, not a framework preference.

Once you understand where the work happens, what it costs, and what the user needs, the choice becomes much easier. Server rendering also introduces one particularly interesting problem: the server can send a page that looks interactive before the browser has actually made it interactive. Understanding what happens during that transition brings us to our next topic.

What’s Next?

In the next article in Beyond the UI, we’ll explore:

Hydration Explained: How Server-Rendered Pages Become Interactive

We’ll follow a server-rendered component from the server to the browser and see how frameworks attach JavaScript behavior to HTML that already exists. We’ll also explore hydration mismatches, why hydration can be expensive, partial and selective hydration, and why newer frontend architectures are trying to ship less JavaScript to the browser.

Because after the server has created your HTML, there’s still one important question:

How does that static HTML become a living application?

The JavaScript Event Loop Explained: Why Your UI Freezes

Billy Okeyo — Mon, 24 Aug 2026 00:00:00 +0000

“Your browser isn’t frozen because JavaScript stopped working. Sometimes it’s frozen because JavaScript won’t stop working long enough for the browser to do anything else.”

In the previous articles in Beyond the UI, we followed the browser rendering pipeline from HTML to pixels and explored why reflow and repaint can make certain UI updates expensive. But there’s another reason an interface can feel slow even when rendering itself isn’t particularly complicated: JavaScript.

Consider this button:

<button id="generate">
    Generate Report
</button>

When clicked, it performs some expensive work.

document
    .querySelector("#generate")
    .addEventListener("click", () => {
        performExpensiveCalculation();
    });

The user clicks the button, and suddenly everything stops. The button doesn’t respond visually, animations freeze, scrolling becomes unresponsive, and other clicks don’t work. Even a loading spinner you tried to display may refuse to appear. Then, a few seconds later, everything suddenly comes back to life.

What happened? The browser didn’t crash, the network wasn’t necessarily slow, and the rendering pipeline wasn’t necessarily doing too much work. The problem was that JavaScript occupied the browser’s main thread for too long.

To understand why that freezes the interface, we need to understand one of the most important concepts in JavaScript:

The Event Loop

At a high level, JavaScript execution in the browser involves several moving parts:

JavaScript Code
      │
      ▼
  Call Stack
      │
      ▼
Browser / Web APIs
      │
      ▼
 Task Queues
      │
      ▼
  Event Loop
      │
      └────────────► Call Stack

But that diagram hides some important details. There are tasks, microtasks, timers, promises, and rendering, and all of them need opportunities to run. Let’s unpack what actually happens.

JavaScript Is Single-Threaded

One of the first things developers learn about JavaScript is that it is single-threaded. At least from the perspective of normal JavaScript execution on the browser’s main thread, only one piece of JavaScript executes at a time.

Consider:

console.log("One");
console.log("Two");
console.log("Three");

The result is predictable:

One
Two
Three

JavaScript doesn’t normally execute all three statements simultaneously. Instead, execution happens one operation at a time. You can think of it like a single cashier serving customers.

Customer A
    │
    ▼
┌──────────┐
│ Cashier  │
└──────────┘
    ▲
    │
Customer B
    │
Customer C

The cashier can serve only one customer at a time. If Customer A takes ten minutes, Customers B and C wait.

The same basic problem exists with JavaScript. If one function takes five seconds to complete, other JavaScript can’t run on that thread during those five seconds. More importantly, much of the browser’s UI work also depends on the main thread getting time to operate. That is where freezing begins.

The Call Stack

JavaScript keeps track of currently executing functions using something called the call stack.

Consider:

function greet() {
    console.log("Hello");
}

function start() {
    greet();
}

start();

Execution begins with start(). Conceptually:

Call Stack

┌──────────────┐
│   start()    │
└──────────────┘

start() calls greet(). Now:

Call Stack

┌──────────────┐
│   greet()    │
├──────────────┤
│   start()    │
└──────────────┘

greet() runs and finishes, then leaves the stack.

┌──────────────┐
│   start()    │
└──────────────┘

Then start() finishes, and the stack becomes empty.

Call Stack

     empty

This matters because queued asynchronous work cannot simply interrupt JavaScript that is already executing. The event loop generally waits for the current task to finish and the call stack to become available before scheduling more work.

So How Does Asynchronous JavaScript Work?

This creates an obvious question: if JavaScript executes one thing at a time, how can this work?

setTimeout(() => {
    console.log("Finished");
}, 2000);

Surely JavaScript doesn’t sit on the call stack for two seconds doing nothing. It doesn’t. The browser provides capabilities outside the JavaScript engine that can handle operations such as timers, networking, and user events. We often refer to these capabilities collectively as Web APIs or browser APIs.

Conceptually:

JavaScript
    │
    │ setTimeout(...)
    ▼
Browser Timer
    │
    │ waits independently
    ▼
Callback becomes eligible

JavaScript registers the timer and continues executing. The browser tracks the timer. Once the timer expires, its callback becomes eligible to run later.

That distinction is important. The callback doesn’t necessarily run immediately when the timer expires. It has to wait until JavaScript is able to execute it.

Why `setTimeout(..., 0)` Doesn’t Mean Immediately

Consider:

console.log("A");

setTimeout(() => {
    console.log("B");
}, 0);

console.log("C");

Some developers initially expect:

A
B
C

But the result is:

A
C
B

Why? Because setTimeout(..., 0) doesn’t mean:

Run this function immediately.

It means something closer to:

After at least the timer delay and once scheduling permits, make this callback available to run as a future task.

So execution looks roughly like:

console.log("A")
        │
        ▼
Register timer
        │
        ▼
console.log("C")
        │
        ▼
Current task finishes
        │
        ▼
Timer callback can run
        │
        ▼
console.log("B")

The timer delay controls when the callback becomes eligible. It doesn’t guarantee exactly when it executes. If the main thread is busy, it may execute much later.

Tasks and the Task Queue

When asynchronous work becomes ready, the browser needs somewhere to keep track of it until JavaScript can execute it. One important category of queued work is commonly called tasks. You may also hear the older term macrotasks.

Examples include work associated with things such as:

Timer callbacks
User interactions
Message events
Certain browser events

Conceptually:

Task Queue

┌─────────────────────────┐
│ click callback          │
├─────────────────────────┤
│ setTimeout callback     │
├─────────────────────────┤
│ message callback        │
└─────────────────────────┘

The event loop coordinates when this queued work gets an opportunity to execute. A simplified model is:

Is JavaScript currently running?
          │
     ┌────┴────┐
     │         │
    Yes        No
     │         │
    Wait       ▼
          Take eligible task
               │
               ▼
          Execute JavaScript

But this is still incomplete, because JavaScript has another important queue.

Enter Microtasks

Promises introduce another category of work called microtasks. Consider:

console.log("A");

Promise.resolve().then(() => {
    console.log("B");
});

console.log("C");

The result is:

A
C
B

That looks similar to setTimeout. But now watch what happens when we combine them.

console.log("A");

setTimeout(() => {
    console.log("B");
}, 0);

Promise.resolve().then(() => {
    console.log("C");
});

console.log("D");

The output is:

A
D
C
B

Why does the promise callback run before the timer? Because promise reactions are scheduled as microtasks, while the timer callback is scheduled as a later task. After the current JavaScript task finishes, the browser drains the microtask queue before moving on to the next task.

A simplified ordering looks like:

Current Task
     │
     ▼
JavaScript executes
     │
     ▼
Current stack finishes
     │
     ▼
Drain Microtasks
     │
     ▼
Rendering may get an opportunity
     │
     ▼
Next Task

So in our example:

A
│
├── Timer scheduled ──────────────► Task Queue
│
├── Promise callback ─────────────► Microtask Queue
│
D
│
▼
Current task ends
│
▼
Microtasks
│
└── C
│
▼
Later task
│
└── B

This distinction between tasks and microtasks explains a surprising amount of JavaScript behavior.

What Creates Microtasks?

Common sources include:

Promise.resolve().then(...)

and code after an awaited promise:

async function load() {
    await fetchData();

    console.log("Finished");
}

The continuation after await eventually resumes through promise machinery and is scheduled as a microtask when the awaited promise settles.

Another browser API is:

queueMicrotask(() => {
    console.log("Microtask");
});

These are useful tools, but microtasks have an important characteristic that can become dangerous:

The browser drains the microtask queue before moving on.

Microtask Starvation

Consider:

function repeat() {
    queueMicrotask(repeat);
}

repeat();

Each microtask creates another microtask.

The browser finishes one:

Microtask 1

but another already exists:

Microtask 2

which creates:

Microtask 3

and so on.

Conceptually:

Task finishes
     │
     ▼
Microtask
     │
     ▼
Creates Microtask
     │
     ▼
Microtask
     │
     ▼
Creates Microtask
     │
     ▼
...

If this continues indefinitely, the browser may struggle to move on to other work. This is called starvation.

Promises are asynchronous, but that doesn’t automatically mean promise-heavy code can never block responsiveness. “Asynchronous” and “runs on another thread” are not the same thing. That’s an important distinction.

Why Your UI Freezes

Now we can finally return to our original problem. Suppose the user clicks a button and you run:

button.addEventListener("click", () => {
    let total = 0;

    for (let i = 0; i < 5_000_000_000; i++) {
        total += i;
    }

    result.textContent = total;
});

Once that click handler begins executing, the main thread is occupied.

Conceptually:

Main Thread

Click Handler
     │
     ▼
Huge Loop
     │
     │
     │  3 seconds
     │
     │
     ▼
Finished

During that time, the browser may have other work waiting.

User scroll
      │
      ├─────────────┐
Button click        │
      │             │
Animation frame     │
      │             ▼
      └──────► WAITING

         Main Thread

      ┌───────────────┐
      │ Expensive JS  │
      │ Expensive JS  │
      │ Expensive JS  │
      │ Expensive JS  │
      └───────────────┘

The page appears frozen because JavaScript isn’t giving the browser enough opportunity to process interactions and produce frames. This is known as a long task.

The Loading Spinner That Never Spins

Here’s a classic example. You want to show a loading state before performing expensive work.

button.addEventListener("click", () => {
    spinner.style.display = "block";

    performExpensiveCalculation();

    spinner.style.display = "none";
});

Logically, this seems correct: show the spinner, do the work, then hide the spinner. But the user may never see the spinner. Why?

Changing:

spinner.style.display = "block";

updates the DOM/style state, but the browser doesn’t necessarily paint the screen immediately after that line. Your JavaScript continues running.

Show spinner
     │
     ▼
Expensive JavaScript
     │
     ▼
Hide spinner
     │
     ▼
Task finishes
     │
     ▼
Browser finally gets chance to render

By the time rendering gets an opportunity, the spinner has already been hidden again. From the user’s perspective, it never appeared.

This connects directly to what we learned in the previous articles:

JavaScript execution and rendering must cooperate on the main thread.

Understanding the rendering pipeline alone isn’t enough. We also need to understand when the browser gets an opportunity to run it.

Rendering and the Event Loop

The browser’s actual scheduling model is sophisticated, and different kinds of work are coordinated according to browser rules. But a useful mental model is:

┌─────────────────────────────┐
│ Execute a Task              │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ Drain Microtasks            │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ Rendering opportunity       │
│ if needed / appropriate     │
└──────────────┬──────────────┘
               │
               ▼
          Next iteration

The key idea is that the browser generally cannot just paint halfway through your long-running synchronous JavaScript function. Your code needs to yield control.

Breaking Expensive Work Into Smaller Pieces

Suppose we need to process one million records. Instead of:

function processRecords(records) {
    for (const record of records) {
        expensiveOperation(record);
    }
}

we could process them in chunks.

function processInChunks(records) {
    let index = 0;

    function processChunk() {
        const end = Math.min(index + 1000, records.length);

        while (index < end) {
            expensiveOperation(records[index]);
            index++;
        }

        if (index < records.length) {
            setTimeout(processChunk, 0);
        }
    }

    processChunk();
}

Instead of one giant task:

┌──────────────────────────────────────────────┐
│              3000ms JavaScript              │
└──────────────────────────────────────────────┘

we create smaller pieces:

JS     Browser     JS     Browser     JS
│         │         │         │        │
▼         ▼         ▼         ▼        ▼

20ms     work      20ms      work     20ms

The total computation may not become dramatically smaller. But responsiveness can improve because the browser gets opportunities to process other work between chunks.

This demonstrates a critical performance principle:

Sometimes making an application feel faster isn’t about doing less work. It’s about scheduling the work more intelligently.

What About `async` and `await`?

A common misconception is that adding async automatically moves expensive work away from the main thread. It doesn’t.

Consider:

async function calculate() {
    let total = 0;

    for (let i = 0; i < 5_000_000_000; i++) {
        total += i;
    }

    return total;
}

Calling:

await calculate();

doesn’t magically make that loop execute on another thread. The synchronous work inside calculate() still runs on the JavaScript thread. async changes how promises and continuations are handled. It doesn’t transform CPU-heavy JavaScript into background work.

This:

async function freezeUI() {
    while (true) {
        // expensive synchronous work
    }
}

will still freeze your interface. async is not a synonym for parallel.

`setTimeout` Isn’t a Background Thread Either

The same misunderstanding often happens with:

setTimeout(() => {
    performExpensiveCalculation();
}, 0);

This doesn’t move the expensive calculation to another thread. It simply schedules the callback to execute as a future task. When that callback eventually runs, the expensive calculation still occupies the main JavaScript thread.

Current Task
     │
     ▼
setTimeout scheduled
     │
     ▼
Current Task finishes
     │
     ▼
Timer Task starts
     │
     ▼
EXPENSIVE WORK
     │
     ▼
UI freezes

You’ve delayed the problem. You haven’t removed it. Chunking can help because each task is smaller, but truly CPU-intensive work may need a different solution.

Web Workers: Actually Moving Work Off the Main Thread

Browsers provide Web Workers for running JavaScript in a background thread separate from the main UI thread. Suppose you need to perform a large calculation. Instead of:

const result = expensiveCalculation(data);

you can create a worker.

const worker = new Worker("worker.js");

worker.postMessage(data);

worker.onmessage = event => {
    console.log("Result:", event.data);
};

Inside worker.js:

self.onmessage = event => {
    const result = expensiveCalculation(event.data);

    self.postMessage(result);
};

Now the architecture looks more like:

Main Thread                      Worker

UI
 │
 ├── User interactions
 │
 ├── Rendering
 │
 └── Send data ────────────────► Expensive calculation
                                      │
                                      │
                                      ▼
 Result received ◄──────────────── Result
 │
 ▼
Update UI

The expensive computation no longer needs to monopolize the main thread. The interface can remain responsive while the worker performs the calculation.

Workers aren’t appropriate for everything. There is communication overhead, data may need to be copied or transferred, and workers don’t directly manipulate the DOM. But for genuinely CPU-heavy operations, they can be extremely valuable.

`requestAnimationFrame`

Now suppose your JavaScript isn’t performing a large calculation. Instead, you’re animating something. You could write:

setInterval(() => {
    moveElement();
}, 16);

But the browser provides a better mechanism specifically for visual updates:

requestAnimationFrame(() => {
    moveElement();
});

requestAnimationFrame tells the browser:

“I want to perform work before an upcoming repaint.”

A typical animation looks like:

let position = 0;

function animate() {
    position += 2;

    element.style.transform =
        `translateX(${position}px)`;

    requestAnimationFrame(animate);
}

requestAnimationFrame(animate);

Conceptually:

Frame
 │
 ├── requestAnimationFrame callback
 │
 ├── Style / Layout
 │
 ├── Paint
 │
 └── Composite
 │
 ▼
Next Frame

This allows your visual updates to align more naturally with the browser’s rendering cycle. It doesn’t mean you can perform unlimited work inside the callback. If your callback takes 100 milliseconds, you’ll still miss frames. requestAnimationFrame gives you appropriate timing. It doesn’t give you unlimited processing power.

Tasks vs Microtasks vs Animation Frames

At this point, we have several scheduling mechanisms. A simplified comparison is useful.

Mechanism	Typical Use
`setTimeout`	Schedule future task
Promise `.then()`	Promise continuation / microtask
`queueMicrotask()`	Explicit microtask
`requestAnimationFrame()`	Work tied to an upcoming visual frame
Web Worker	CPU-heavy work away from main UI thread

These mechanisms aren’t interchangeable. For example, using a chain of promises to split heavy work may not provide the rendering opportunities you expect because microtasks are drained before the browser moves on.

Consider:

function process() {
    Promise.resolve().then(process);
}

process();

This can continually populate the microtask queue. If your goal is to yield so the browser can render, continuously scheduling microtasks may be exactly the wrong strategy. Understanding which queue your work enters matters.

A Practical Example: Processing a Large Dataset

Suppose a dashboard receives 100,000 records and needs to calculate statistics. The naive approach:

button.addEventListener("click", () => {
    const result = calculateStatistics(records);

    renderResults(result);
});

If the calculation takes two seconds:

Click
 │
 ▼
Calculate Statistics
 │
 │ 2 seconds
 │
 ▼
Render Results

the UI may become unresponsive. One option is chunking:

Chunk 1
   │
   ▼
Yield
   │
   ▼
Chunk 2
   │
   ▼
Yield
   │
   ▼
Chunk 3

Another option, particularly for CPU-heavy computation, is a worker:

                    ┌──────────────────┐
Records ───────────►│    Web Worker    │
                    │                  │
UI remains          │ Calculate stats  │
responsive          │                  │
                    └────────┬─────────┘
                             │
                             ▼
                           Result

The right approach depends on the workload. But both are better than assuming async will solve the problem automatically.

Long Tasks and the 16.7ms Frame Budget

In the previous articles, we discussed the frame budget. On a 60 Hz display, the browser gets a new frame opportunity roughly every:

1000ms / 60 ≈ 16.7ms

Now imagine JavaScript runs for 200 milliseconds.

Frame budget

|----16.7ms----|

JavaScript

|----------------------------------------------------|
                       200ms

Several potential frame opportunities pass while JavaScript is still executing. Animations stop updating smoothly, interactions feel delayed, and the page becomes janky.

This is why long-running JavaScript matters even when the total amount of computation seems reasonable. Users experience responsiveness in small windows of time. A two-second calculation that completely blocks the interface feels much worse than work that can be performed without preventing interaction.

The Event Loop Explains Delayed Clicks Too

Freezing isn’t always dramatic. Sometimes the interface simply feels slightly sluggish.

Suppose the main thread is busy for 300 milliseconds. During that period, the user clicks a button. The click doesn’t disappear. It can wait until the browser is able to process the relevant event and run its handler.

Conceptually:

User clicks
     │
     ▼
Event waiting
     │
     │
     │ Main thread busy
     │
     ▼
JavaScript finishes
     │
     ▼
Click handler runs

From the user’s perspective:

“I clicked the button and nothing happened.”

Then, a fraction of a second later, the interface responds. This is one reason JavaScript performance directly affects interaction responsiveness. It’s also why modern web performance metrics care about how quickly pages respond to user interactions, not merely how quickly they initially load.

Frameworks Still Depend on the Event Loop

Just as React cannot bypass the browser rendering pipeline, frameworks cannot bypass JavaScript scheduling.

Consider:

function App() {
    const handleClick = () => {
        performHugeCalculation();
        setResult("Finished");
    };

    return (
        <button onClick={handleClick}>
            Calculate
        </button>
    );
}

React can optimize how updates are reconciled. But if performHugeCalculation() occupies the main thread for three seconds, React cannot magically make the browser responsive during that synchronous work. The same principle applies to Vue, Angular, Svelte, Solid, and every other browser-based framework.

Eventually:

Framework Event Handler
          │
          ▼
      JavaScript
          │
          ▼
     Main Thread
          │
     ┌────┴─────┐
     │          │
Long work    Short work
     │          │
     ▼          ▼
UI blocked   Browser gets
             opportunities
             to continue

Understanding the event loop is therefore framework-independent knowledge.

Common Event Loop Mistakes

Several bugs and performance problems become easier to recognize once you understand scheduling. One is assuming this executes immediately:

setTimeout(callback, 0);

It doesn’t. Another is assuming this moves CPU work off the main thread:

async function work() {
    expensiveCalculation();
}

It doesn’t. Another is creating enormous promise or microtask chains and assuming that because they’re asynchronous, rendering will happen between each one. That isn’t necessarily true.

And perhaps the most common mistake is simply doing too much synchronous work inside event handlers.

button.addEventListener("click", () => {
    parseHugeFile();
    calculateStatistics();
    transformRecords();
    generateReport();
    updateDashboard();
});

Each individual function may look reasonable. Together, they can monopolize the main thread.

How to Keep the UI Responsive

The goal isn’t to avoid JavaScript. It’s to cooperate with the browser.

For large amounts of work, consider breaking processing into smaller chunks so the browser gets opportunities to handle other tasks. For CPU-heavy work that doesn’t need DOM access, consider Web Workers. For visual updates, use requestAnimationFrame where appropriate. Avoid unnecessarily long synchronous event handlers. Be careful about creating endless microtask chains.

And most importantly, measure. Browser developer tools can show long tasks, scripting time, rendering activity, and frame performance. A slow interface shouldn’t lead immediately to random optimization. First determine whether the bottleneck is:

JavaScript execution?
        │
        ├── Long task?
        ├── Too many calculations?
        └── Excessive framework work?

Rendering?
        │
        ├── Layout?
        ├── Paint?
        └── Compositing?

Network?
        │
        └── Waiting for resources?

Different problems require different solutions.

Putting the Event Loop Together

We can now build a more complete mental model.

                 Browser
                    │
       ┌────────────┴─────────────┐
       │                          │
       ▼                          ▼
  Browser APIs               User Events
       │                          │
       └────────────┬─────────────┘
                    │
                    ▼
                Task Queue
                    │
                    ▼
              ┌───────────┐
              │ Event Loop│
              └─────┬─────┘
                    │
                    ▼
               Call Stack
                    │
                    ▼
             JavaScript Runs
                    │
                    ▼
              Task Finishes
                    │
                    ▼
            Drain Microtasks
                    │
                    ▼
         Rendering Opportunity
                    │
                    ▼
               Next Work

Again, the browser’s actual implementation is more sophisticated than this diagram. But as a mental model, it answers many practical questions.

Why doesn’t setTimeout(..., 0) run immediately? Because it has to wait for a future task opportunity.

Why does a promise callback run before that timer? Because microtasks are processed before moving on to the next task.

Why does a giant loop freeze the interface? Because JavaScript occupies the main thread.

Why didn’t your spinner appear before the expensive calculation? Because the browser didn’t get a rendering opportunity.

Why doesn’t async solve CPU-heavy work? Because asynchronous syntax doesn’t automatically mean another thread.

Why can Web Workers help? Because they allow computation to happen away from the main UI thread.

Bringing It All Together

The JavaScript event loop isn’t merely an interview question. It’s the scheduling system behind much of the behavior users experience in web applications.

When JavaScript performs small amounts of work and regularly gives control back to the browser, the interface remains responsive.

JavaScript
    │
    ▼
Browser
    │
    ▼
JavaScript
    │
    ▼
Browser
    │
    ▼
JavaScript

But when one task monopolizes the main thread:

JavaScript
    │
    │
    │
    │
    │
    │
    ▼
Finally finishes
    │
    ▼
Browser catches up

everything else has to wait. That’s the heart of the problem.

A responsive frontend isn’t just about writing fast JavaScript. It’s about giving the browser enough opportunities to do everything other than JavaScript.

Final Thoughts

The event loop can seem complicated because several concepts are usually introduced at once: the call stack, Web APIs, tasks, microtasks, promises, timers, rendering, and animation frames. But underneath all of them is a relatively simple idea.

The browser has many responsibilities. It needs to run your JavaScript, respond to users, calculate layouts, paint pixels, animate interfaces, and process network results. And much of that work has to be coordinated around a main thread that can only do so much at once.

If your JavaScript refuses to give that thread back, the browser cannot provide a smooth experience. That’s why the next time your interface freezes, the most useful question may not be:

“Why is this function slow?”

Instead, ask:

“How long am I preventing the browser from doing anything else?”

That question gets much closer to how users actually experience performance.

What’s Next?

So far in Beyond the UI, we’ve looked underneath frontend frameworks at three fundamental browser concepts:

Browser Rendering Pipeline
          │
          ▼
Reflow and Repaint
          │
          ▼
JavaScript Event Loop

We now understand how the browser creates pixels, why some visual updates are expensive, and why JavaScript can prevent the UI from responding altogether.

Next, we’ll move one level higher and look at a decision that shapes how modern frontend applications are delivered:

Client-Side Rendering vs Server-Side Rendering Explained: Where Should Your UI Be Built?

We’ll explore CSR, SSR, static generation, the trade-offs between them, what happens from the moment a user requests a page, and why frameworks such as Next.js, Nuxt, and modern meta-frameworks increasingly blur the line between client and server.

Because once you understand how the browser renders, the next question becomes:

How much work should we make the browser do in the first place?

Reflow and Repaint Explained: Why Some UI Updates Are Expensive

Billy Okeyo — Fri, 21 Aug 2026 00:00:00 +0000

“Changing one CSS property can be almost free. Changing another can force the browser to recalculate half the page. Understanding why is the difference between guessing at frontend performance and reasoning about it.”

In the previous article in Beyond the UI, we followed a webpage through the browser rendering pipeline. We started with HTML and CSS and eventually arrived at pixels:

HTML ──────► DOM
               │
CSS ───────► CSSOM
               │
               ▼
          Render Tree
               │
               ▼
            Layout
               │
               ▼
             Paint
               │
               ▼
          Compositing
               │
               ▼
             Pixels

That pipeline explains how a page appears for the first time. But modern websites don’t remain still after they’re rendered. A user opens a menu, a notification appears, a modal slides onto the screen, an accordion expands, JavaScript adds another row to a table, an animation moves a card across the page, and a validation message appears underneath a form field. Every one of these interactions changes something the browser has already rendered.

The interesting question is:

How much work does the browser have to repeat when something changes?

The answer depends heavily on what changed. Changing an element’s width may affect the position of everything around it. Changing its background color doesn’t affect its geometry, but the browser still needs to redraw it. Changing its transform may, in favorable circumstances, avoid both layout and painting and require mostly compositing work.

Conceptually, these updates can look very different:

Width Change

Style
  │
  ▼
Layout
  │
  ▼
Paint
  │
  ▼
Composite

Compared with:

Background Change

Style
  │
  ▼
Paint
  │
  ▼
Composite

And sometimes:

Transform / Opacity

Style
  │
  ▼
Composite

These are simplified mental models rather than guarantees, but they reveal something fundamental about frontend performance:

Not all UI updates cost the browser the same amount of work.

To understand why, we need to look more closely at two terms that appear constantly in frontend performance discussions: Reflow and Repaint.

What Is Reflow?

Imagine a simple page containing three cards.

┌───────────────────────────┐
│ Card A                    │
│ height: 100px             │
└───────────────────────────┘

┌───────────────────────────┐
│ Card B                    │
│ height: 100px             │
└───────────────────────────┘

┌───────────────────────────┐
│ Card C                    │
│ height: 100px             │
└───────────────────────────┘

The browser has already calculated where every card belongs. Then JavaScript changes the height of Card A.

const card = document.querySelector(".card-a");

card.style.height = "300px";

Card A can no longer occupy the same amount of space. That means Card B must move, and Card C must move as well. The browser needs to recalculate the geometry of the affected part of the page.

Before

Card A     y = 0
Card B     y = 120
Card C     y = 240


After Card A grows

Card A     y = 0
Card B     y = 320
Card C     y = 440

That recalculation is commonly called reflow. In modern browser terminology, you’ll also frequently see it called layout. During layout, the browser may need to recalculate things such as:

Width
Height
Position
Margins
Padding
Relationships between parents and children
Text wrapping
Available space

The important part is that a layout change isn’t always isolated to the element you modified. One element can influence many others.

Why Reflow Can Become Expensive

Suppose you change the width of a paragraph.

.article {
    width: 600px;
}

Then later:

article.style.width = "400px";

The browser doesn’t simply make the rectangle narrower. Text may wrap differently, which changes the paragraph’s height, and everything below the paragraph may move. If the paragraph is inside another container whose height depends on its children, that container may also change, and now its siblings may need new positions. A single modification can ripple through the page.

Change width
     │
     ▼
Text wraps differently
     │
     ▼
Element height changes
     │
     ▼
Parent geometry changes
     │
     ▼
Sibling positions change
     │
     ▼
Layout recalculated

On a tiny page, this may take almost no noticeable time. On a large dashboard containing thousands of elements, complex grids, tables, charts, and nested components, repeated layout work can become expensive. This is particularly dangerous when it happens many times during a single animation or interaction.

What Can Trigger Reflow?

Many operations can invalidate layout because they change geometry or influence how elements are positioned. Common examples include modifying:

width
height
margin
padding
top
left
right
bottom
font-size
line-height

Adding or removing DOM elements can also require layout.

container.appendChild(newElement);

So can changing content.

title.textContent =
    "This is a much longer title than before";

The new text may wrap differently, changing the size of the element and potentially shifting everything around it. Even resizing the browser window can trigger significant layout work because responsive layouts may need to be recalculated. But writes aren’t the only thing developers need to think about. Sometimes reading information from the DOM can cause performance problems too.

The Surprising Cost of Reading Layout

Consider this code:

const width = element.offsetWidth;

It looks harmless. We’re only asking the browser for a number. But imagine the browser already knows that something changed.

element.style.width = "500px";

const width = element.offsetWidth;

The first line modifies layout. However, browsers often delay expensive rendering work until it is actually needed. Then the second line asks:

“What is the element’s width right now?”

The browser cannot answer accurately using the old layout information. It may therefore need to calculate layout immediately before returning the value. Conceptually:

Change width
     │
     ▼
Layout becomes invalid
     │
     ▼
Read offsetWidth
     │
     ▼
Browser needs current geometry
     │
     ▼
Forced Layout

This becomes especially problematic when reads and writes are repeatedly mixed together. And that leads us to one of the most notorious frontend performance problems.

Layout Thrashing Explained

Imagine you have 500 elements. You want to increase each one’s width slightly. You write:

const items = document.querySelectorAll(".item");

items.forEach(item => {
    const width = item.offsetWidth;

    item.style.width = `${width + 10}px`;
});

At first glance, this looks reasonable. Read the current width, add ten pixels, and move to the next element. But look at the pattern:

READ
WRITE

READ
WRITE

READ
WRITE

READ
WRITE

After a write, layout may become invalid. The next read asks the browser for current geometry, so the browser may need to calculate layout. Then another write invalidates it again, and another read may force layout again. You can end up with something conceptually similar to:

Read
  │
Write
  │
Layout
  │
Read
  │
Write
  │
Layout
  │
Read
  │
Write
  │
Layout
  │
...

This repeated invalidation and recalculation is commonly known as layout thrashing. Instead, you generally want to group reads together and then group writes together.

const items = [...document.querySelectorAll(".item")];

const widths = items.map(item => item.offsetWidth);

items.forEach((item, index) => {
    item.style.width = `${widths[index] + 10}px`;
});

Now the pattern becomes:

READ
READ
READ
READ

     ↓

WRITE
WRITE
WRITE
WRITE

This gives the browser much more opportunity to batch its work. The lesson is broader than this particular example:

Avoid repeatedly switching between reading layout information and modifying layout inside tight loops.

What Is Repaint?

Now imagine a different situation. You don’t change the size or position of an element. You simply change its background.

card.style.backgroundColor = "blue";

The card remains in exactly the same place. Its width doesn’t change, its height doesn’t change, and its siblings don’t move. The browser therefore doesn’t necessarily need to recalculate layout. But the card looks different, so the pixels representing it must be updated. This is where repaint comes in. Conceptually:

Before

┌─────────────────┐
│                 │
│   Gray Card     │
│                 │
└─────────────────┘

       ↓

background-color changes

       ↓

┌─────────────────┐
│                 │
│   Blue Card     │
│                 │
└─────────────────┘

The geometry hasn’t changed. The appearance has. The browser needs to paint the affected visual content again.

Reflow vs Repaint

This distinction is worth making clear. A reflow deals primarily with geometry. A repaint deals primarily with appearance. Consider these two updates.

element.style.width = "500px";

and:

element.style.backgroundColor = "red";

The first can affect layout. The second generally doesn’t. A simplified comparison looks like this:

Change	Layout	Paint	Composite
`width`	Usually	Usually	Usually
`height`	Usually	Usually	Usually
`padding`	Usually	Usually	Usually
`font-size`	Usually	Usually	Usually
`background-color`	No layout in typical cases	Usually	Usually
`box-shadow`	No layout in typical cases	Usually	Usually
`transform`	Often avoidable	Often avoidable	Often
`opacity`	Often avoidable	Often avoidable	Often

This table is intentionally simplified. Browser engines are highly optimized, and exactly what gets recalculated depends on the page, browser, element, layer structure, and other factors. The useful mental model is the hierarchy:

Layout
  │
  ▼
Paint
  │
  ▼
Composite

If you invalidate layout, later stages may also need work. If you only invalidate paint, layout may be avoided. If an update can be handled during compositing, both layout and painting may sometimes be avoided. This is why avoiding unnecessary layout work can be so valuable.

Compositing: The Cheaper Path

Suppose you want to animate a card from left to right. One approach is changing left.

.card {
    position: absolute;
    left: 0;
}

Then:

card.style.left = "300px";

Because left participates in positioning, changing it can require layout work. Now consider:

card.style.transform = "translateX(300px)";

A transform changes how the already-rendered element is presented. In many situations, browsers can handle transforms efficiently during compositing, particularly when the element is on its own composited layer. The difference can look conceptually like this:

Animating left

JavaScript
    │
    ▼
Layout
    │
    ▼
Paint
    │
    ▼
Composite

versus:

Animating transform

JavaScript
    │
    ▼
Composite

This is why transform and opacity are commonly recommended for animations. For example:

.modal {
    opacity: 0;
    transform: translateY(20px);

    transition:
        opacity 200ms ease,
        transform 200ms ease;
}

.modal.open {
    opacity: 1;
    transform: translateY(0);
}

Rather than animating:

top
left
width
height

you give the browser a better opportunity to perform the animation without repeatedly recalculating page geometry. But there’s an important warning here.

Don’t Turn “Use Transform” Into Another Rule to Memorize

Frontend performance advice often becomes simplified into statements like:

Always animate transform.

Or:

transform doesn’t cause repaint.

Those statements are useful shortcuts, but reality is more nuanced. Browsers make their own decisions about compositing layers. Effects such as filters, clipping, large painted areas, and complex descendants can influence how much work an animation requires. Hardware, browser versions, and the structure of the page matter too.

So instead of memorizing:

transform = fast

remember the deeper idea:

Prefer updates that allow the browser to avoid repeating earlier, more expensive stages of the rendering pipeline.

Then measure what actually happens.

`will-change`: Useful but Easy to Abuse

CSS provides a property called will-change. For example:

.card {
    will-change: transform;
}

You’re essentially giving the browser a hint:

“This element is likely to change in this way soon.”

The browser may use that information to prepare optimizations ahead of time, potentially including promoting the element to its own compositing layer. That can be useful for animations that are known to be performance-sensitive. But this does not mean you should do this:

* {
    will-change: transform;
}

Compositing layers aren’t free. They consume memory and other resources, and creating unnecessary layers can make performance worse rather than better. will-change should therefore be treated as a targeted optimization, not a default styling strategy.

DOM Updates and Reflow

Another common source of rendering work is repeatedly modifying the DOM. Imagine adding 1,000 rows to a table. A naive implementation might look like:

for (let i = 0; i < 1000; i++) {
    const row = document.createElement("tr");

    row.innerHTML = `
        <td>${i}</td>
        <td>Customer ${i}</td>
    `;

    table.appendChild(row);
}

Modern browsers are good at batching work, so this doesn’t automatically mean 1,000 complete reflows. Still, repeatedly touching the live DOM can create unnecessary work, especially when your code also performs layout reads or other operations between writes. One option is constructing the changes away from the live document first.

const fragment = document.createDocumentFragment();

for (let i = 0; i < 1000; i++) {
    const row = document.createElement("tr");

    row.innerHTML = `
        <td>${i}</td>
        <td>Customer ${i}</td>
    `;

    fragment.appendChild(row);
}

table.appendChild(fragment);

The browser receives the collection of new nodes together. The broader principle is more important than DocumentFragment itself:

Batch related DOM updates where practical instead of constantly alternating between DOM writes and layout-dependent reads.

Modern frameworks often help organize updates for you, but they cannot eliminate poor rendering patterns entirely.

React Doesn’t Make Reflow Disappear

Suppose you’re using React. You write:

function Sidebar({ open }) {
    return (
        <aside
            className={open ? "sidebar open" : "sidebar"}
        >
            Menu
        </aside>
    );
}

React determines what needs to change in the DOM. But after React updates the DOM, the browser still has to render the result. If your CSS says:

.sidebar {
    width: 0;
    transition: width 300ms;
}

.sidebar.open {
    width: 300px;
}

the browser may need to perform layout repeatedly while that width is being animated. React’s reconciliation algorithm doesn’t remove that cost. The same applies to Vue, Angular, Svelte, Solid, and other frameworks. Frameworks determine what DOM changes should happen. The browser determines how those changes become pixels.

Application State
       │
       ▼
Framework
       │
       ▼
DOM Update
       │
       ▼
Browser
       │
       ├── Layout?
       ├── Paint?
       └── Composite?

This distinction is important. A highly optimized React component can still produce expensive browser rendering work.

A Real-World Example: Expanding an Accordion

Imagine an FAQ section. When the user clicks a question, the answer expands. A common implementation animates height.

.answer {
    height: 0;
    overflow: hidden;
    transition: height 300ms;
}

.answer.open {
    height: 200px;
}

The animation looks simple. But as the height changes:

0px
20px
40px
60px
80px
...
200px

the elements underneath may need to move during each stage. Conceptually:

Answer grows
    │
    ▼
Layout changes
    │
    ▼
Content below moves
    │
    ▼
Paint
    │
    ▼
Composite

This doesn’t automatically mean the animation is unacceptable. Sometimes layout animation is exactly what the design requires, and modern devices may handle it perfectly well. Performance engineering isn’t about eliminating every reflow. It’s about avoiding unnecessary or excessive work. That’s an important distinction.

Reflow Is Not the Enemy

After learning about layout performance, it’s easy to become afraid of reflow. Don’t. Browsers are designed to perform layout, and changing layouts is a fundamental part of building interactive webpages. Adding a message to the page, opening a navigation menu, rendering search results, or resizing a responsive application may all require layout, and none of these are inherently bad. The problem arises when we force the browser to repeat expensive work unnecessarily.

This:

One user action
      │
      ▼
One coordinated DOM update
      │
      ▼
Layout
      │
      ▼
Paint

is perfectly normal.

This is more concerning:

One user action
      │
      ▼
Read
Write
Layout
Read
Write
Layout
Read
Write
Layout
Read
Write
Layout
...

Optimization is usually about reducing redundant work, not eliminating legitimate rendering work.

Measuring Reflow and Repaint

You don’t have to guess whether your page is doing too much rendering work. Modern browsers provide performance profiling tools. In Chrome DevTools, for example, the Performance panel can record what happens during an interaction. You may see work categorized around:

Scripting

Rendering / Layout

Painting

Compositing

Suppose clicking a button causes a visible delay. Instead of immediately rewriting your React components, record the interaction. Perhaps JavaScript is the problem, layout takes too long, a huge section of the page is being repainted, or the main thread is busy doing unrelated work. The browser’s profiling tools help answer those questions.

This leads to one of the most useful rules in frontend performance:

Measure before you optimize.

A theoretical optimization that saves 0.2 milliseconds isn’t worth making your code significantly harder to maintain. Focus on bottlenecks users can actually experience.

Practical Ways to Reduce Rendering Work

Once you understand the rendering pipeline, several optimization techniques start to make sense naturally. When animating movement, prefer transform where it achieves the same visual result.

transform: translateX(100px);

When fading elements, prefer opacity.

opacity: 0;

Avoid repeatedly alternating layout reads and writes. Instead of:

READ → WRITE → READ → WRITE

prefer:

READ → READ → READ
          │
          ▼
WRITE → WRITE → WRITE

Batch related DOM updates where possible. Avoid unnecessary manipulation of large parts of the DOM. Be cautious with expensive visual effects on large or frequently changing areas. Use will-change only when profiling suggests it is useful. And most importantly, use browser performance tools to confirm where your application is spending time. These aren’t arbitrary “frontend best practices.” Every one of them follows from the same idea:

Give the browser less unnecessary work to do before the next frame must appear.

The 16.7ms Problem

In the previous article, we introduced the idea of the browser’s frame budget. On a 60 Hz display, a new frame is available roughly every:

1000ms / 60 ≈ 16.7ms

That doesn’t mean your JavaScript gets the entire 16.7 milliseconds. The browser may also need to perform:

JavaScript
     │
     ▼
Style Calculation
     │
     ▼
Layout
     │
     ▼
Paint
     │
     ▼
Composite

If your code triggers repeated layout calculations and expensive paints, the browser may not finish everything before the next frame is due. A frame gets missed, then another. The user sees:

Smooth

● ● ● ● ● ● ● ● ● ●


Janky

● ●   ●     ● ●    ●

This is why rendering performance directly affects how an interface feels. Users don’t know that your page suffered a forced synchronous layout. They simply know that dragging the panel felt sluggish.

Bringing It All Together

Reflow and repaint aren’t mysterious browser behaviors. They’re consequences of how browsers turn changing documents into pixels. When geometry changes, the browser may need to recalculate layout.

Change width / height / position
              │
              ▼
            Layout
              │
              ▼
             Paint
              │
              ▼
          Composite

When only appearance changes, layout may be avoided.

Change visual property
          │
          ▼
         Paint
          │
          ▼
      Composite

And some changes may be handled primarily during compositing.

Transform / Opacity
          │
          ▼
      Composite

Again, these are simplified mental models, not guarantees. But they give us a much better way to reason about frontend performance. Instead of asking:

“Which CSS properties are fast?”

we can ask:

“Which parts of the rendering pipeline does this update require the browser to repeat?”

That’s the question that scales beyond individual tricks.

Final Thoughts

Frontend performance is often taught as a collection of rules: use transform, avoid changing width, don’t touch the DOM too much, use requestAnimationFrame, and avoid forced layouts. Those recommendations can be useful, but memorizing them without understanding the browser makes them fragile. Once you understand reflow and repaint, the rules start explaining themselves. Changing geometry can require layout. Changing appearance can require painting. Some visual changes can be handled efficiently during compositing. Repeatedly forcing the browser backwards through that pipeline can consume the limited time available for each frame.

The goal isn’t to build an application that never triggers reflow or repaint. That’s unrealistic. The goal is to make those operations intentional rather than accidental. And perhaps the most dangerous accidental performance problem is one we’ve already encountered in this article: JavaScript asks the browser for information, changes something, asks for more information, changes something again, and continues doing this while the browser desperately tries to keep its layout up to date.

To understand why that happens, we need to understand how JavaScript itself gets scheduled.

What’s Next?

In the next article in Beyond the UI, we’ll move from rendering into JavaScript execution:

The JavaScript Event Loop Explained: Why Your UI Freezes

We’ll explore the call stack, Web APIs, tasks, microtasks, promises, timers, and requestAnimationFrame, and see why an innocent-looking piece of JavaScript can prevent an entire interface from responding. Because sometimes your UI isn’t slow because the browser is painting too much. Sometimes the browser simply doesn’t get a chance to paint at all.

The Browser Rendering Pipeline Explained: From HTML to Pixels

Billy Okeyo — Mon, 17 Aug 2026 00:00:00 +0000

“You write HTML and CSS. The browser’s job is to somehow turn them into pixels. What happens in between is one of the most important things a frontend developer can understand.”

Introduction

Open a browser and visit almost any website. Within milliseconds, text appears, buttons take shape, images load, colors fill the screen, and complex layouts arrange themselves into something you can interact with.

As developers, we usually think about the code responsible for that interface. We write something like:

<div class="card">
    <h2>Welcome Back</h2>
    <p>You have 3 new notifications.</p>
    <button>View Notifications</button>
</div>

Then we add some CSS:

.card {
    padding: 24px;
    border-radius: 12px;
}

.card h2 {
    font-size: 24px;
}

We refresh the browser and see a card. It feels almost instantaneous. But the browser cannot display HTML, and it cannot display CSS either. Your monitor ultimately understands pixels.

Somewhere between receiving this:

<h1>Hello World</h1>

and displaying Hello World on the screen, the browser has to parse the document, understand its structure, determine which CSS rules apply, calculate the size and position of elements, determine what needs to be drawn, organize those drawings into layers, and finally send the result to the screen.

That journey is known as the browser rendering pipeline.

At a high level, it looks something like this:

HTML
 │
 ▼
DOM

CSS
 │
 ▼
CSSOM

DOM + CSSOM
     │
     ▼
 Render Tree
     │
     ▼
   Layout
     │
     ▼
   Paint
     │
     ▼
Compositing
     │
     ▼
   Pixels

Understanding this pipeline changes the way you think about frontend development. Suddenly, performance problems such as layout thrashing, expensive animations, unnecessary repaints, and large stylesheets stop feeling mysterious. You begin to understand why certain operations are expensive rather than simply memorizing that they should be avoided.

So let’s follow a webpage from the moment the browser receives its HTML to the moment pixels appear on your screen.

Step 1: The Browser Receives HTML

Suppose you navigate to:

https://example.com

After the networking work required to obtain the document, the browser begins receiving HTML. Importantly, it doesn’t necessarily wait for the entire document before doing anything. HTML can be processed progressively as bytes arrive over the network.

Imagine the server sends:

<!DOCTYPE html>
<html>
<head>
    <title>My Store</title>
</head>

<body>
    <main>
        <h1>Products</h1>

        <div class="product">
            <h2>Laptop</h2>
            <p>KES 75,000</p>
        </div>
    </main>
</body>
</html>

To us, this is a text document. To the browser, it’s a set of instructions describing the structure of a page. The first major job is converting that text into something the browser can work with. That something is the DOM.

Step 2: Building the DOM

DOM stands for Document Object Model. The browser parses the HTML and converts its elements into a tree of objects. Our previous HTML becomes conceptually similar to this:

Document
│
└── html
    │
    ├── head
    │   └── title
    │       └── "My Store"
    │
    └── body
        │
        └── main
            │
            ├── h1
            │   └── "Products"
            │
            └── div.product
                │
                ├── h2
                │   └── "Laptop"
                │
                └── p
                    └── "KES 75,000"

This tree is the DOM. The DOM isn’t simply a copy of the HTML file. It’s the browser’s in-memory representation of the document. That’s why JavaScript can do things like:

const title = document.querySelector("h1");

title.textContent = "Featured Products";

JavaScript isn’t editing your original HTML file. It’s modifying the DOM that the browser constructed from it. Once that DOM changes, the browser may need to perform additional rendering work so the screen reflects the new state.

We’ll come back to that shortly. For now, we have structure. But the browser still doesn’t know what the page should look like. For that, it needs CSS.

Step 3: Building the CSSOM

Suppose our document references a stylesheet.

<link rel="stylesheet" href="https://billyokeyo.dev/styles.css">

And that stylesheet contains:

body {
    font-family: Arial, sans-serif;
}

.product {
    padding: 20px;
    border: 1px solid #ddd;
}

.product h2 {
    font-size: 24px;
}

Just as the browser doesn’t directly work with raw HTML when rendering the page, it doesn’t simply treat CSS as a collection of strings. It parses the CSS and constructs another representation called the CSS Object Model, or CSSOM.

Conceptually:

CSSOM
│
├── body
│   └── font-family: Arial
│
└── .product
    │
    ├── padding: 20px
    ├── border: 1px solid #ddd
    │
    └── h2
        └── font-size: 24px

The real CSSOM is considerably more sophisticated because CSS involves inheritance, specificity, cascading rules, media queries, browser defaults, and many other considerations. But the important idea is simple. The browser now has two important pieces of information.

The DOM tells it:

What exists?

The CSSOM helps determine:

What should it look like?

Now the browser can begin combining them.

Step 4: Creating the Render Tree

The browser doesn’t simply draw every node in the DOM. Some elements shouldn’t appear on screen.

Consider:

<div class="message">
    Payment successful
</div>

<div class="debug">
    Internal debugging information
</div>

With:

.debug {
    display: none;
}

The .debug element exists in the DOM. JavaScript can still find it.

document.querySelector(".debug");

But it doesn’t need to be rendered. This is why the browser constructs another structure: the render tree. The render tree combines relevant DOM nodes with their computed styles and contains the visual elements that need to participate in layout and painting.

Conceptually:

DOM                       CSSOM
 │                          │
 └────────────┬─────────────┘
              │
              ▼
         Render Tree
              │
      Visible elements
      + computed styles

An element with:

display: none;

doesn’t generate a box in the render tree.

There are some important subtleties here. For example:

visibility: hidden;

is different. The element is invisible, but it still occupies space in the layout. Understanding these differences becomes important when optimizing interfaces.

At this point, the browser knows what needs to be rendered and how it should look. But there’s still one major question. Where exactly should everything go?

Step 5: Layout: Calculating Geometry

Consider this CSS:

.container {
    width: 80%;
}

.card {
    width: 50%;
    padding: 20px;
}

What does 50% actually mean in pixels? That depends on the size of the parent, and the parent’s size might depend on its parent. The browser therefore needs to calculate the geometry of the page. This stage is commonly called layout.

During layout, the browser determines things such as:

Element width
Element height
X position
Y position
Margins
Padding
Relationships between elements

Imagine a viewport that is 1200 pixels wide.

If:

.container {
    width: 80%;
}

then the container may become:

960px

A child with:

width: 50%;

may therefore become:

480px

The browser performs these calculations throughout the relevant layout tree. The result might conceptually look like:

Viewport: 1200 × 800

┌───────────────────────────────────────┐
│ Header                                │
│ x: 0   y: 0                           │
│ width: 1200   height: 80              │
├───────────────────────────────────────┤
│                                       │
│   Product Card                        │
│   x: 120   y: 120                     │
│   width: 480   height: 220            │
│                                       │
└───────────────────────────────────────┘

The browser now knows exactly where elements belong. And this is where frontend performance starts becoming particularly interesting.

Why Layout Can Be Expensive

Suppose JavaScript changes the width of an element.

element.style.width = "800px";

That change may affect much more than that one element. Its children may need to move. Its siblings may need to move. Its parent’s dimensions might change. Other parts of the page may need to be recalculated. The browser may therefore need to perform layout again. This is commonly referred to as reflow.

Consider a list:

┌─────────────────────┐
│ Item 1              │
├─────────────────────┤
│ Item 2              │
├─────────────────────┤
│ Item 3              │
├─────────────────────┤
│ Item 4              │
└─────────────────────┘

If Item 1 suddenly becomes three times taller, Items 2, 3, and 4 may all need new positions. One small change has affected several elements. This is why repeatedly modifying layout-related properties can hurt performance, especially on complex pages.

But calculating positions still doesn’t put anything on the screen. The browser now needs to draw.

Step 6: Paint: Turning Elements Into Drawing Instructions

Once layout is complete, the browser knows what should appear and where it belongs. Now it needs to determine how to draw it. This is the paint stage.

Consider a button:

button {
    background: blue;
    color: white;
    border-radius: 8px;
    box-shadow: 0 4px 10px rgba(0,0,0,.2);
}

Painting may involve drawing:

The background
The border
The text
The rounded corners
The shadow

The browser creates painting instructions representing these visual operations.

Conceptually:

Layout

Button:
x = 100
y = 200
width = 160
height = 48

        │
        ▼

Paint

Draw background
Draw border
Draw shadow
Draw text

Some visual effects are considerably more expensive to paint than others. Large shadows, complex gradients, filters, and large areas that change frequently can increase rendering work. This is why performance problems aren’t always caused by JavaScript. Sometimes the browser simply has too much visual work to perform.

Step 7: Compositing

Modern webpages are often too complicated to paint as one giant flat image every time something changes. Browsers can divide parts of the page into separate compositing layers.

Imagine a page containing:

Background

Content

Navigation

Modal

Animation

Conceptually, the browser might treat these as layers:

          ┌─────────────┐
          │    Modal    │
          └─────────────┘
                 ▲
          ┌─────────────┐
          │ Navigation  │
          └─────────────┘
                 ▲
          ┌─────────────┐
          │   Content   │
          └─────────────┘
                 ▲
          ┌─────────────┐
          │ Background  │
          └─────────────┘

During compositing, those layers are assembled in the correct order to produce the final image. This is especially important for animations.

Suppose you animate an element using:

transform: translateX(200px);

In favorable cases, the browser can move an already-painted composited layer rather than recalculating the layout and repainting large parts of the page.

Compare that with repeatedly changing:

left: 200px;

Depending on the page and positioning context, changing left may trigger layout and subsequent rendering work. This is one reason frontend performance advice often recommends animating properties such as:

transform
opacity

when appropriate. The recommendation isn’t arbitrary. It comes directly from understanding how browsers render pages.

Putting the Entire Pipeline Together

We can now see the full journey.

                 HTML
                   │
                   ▼
              Parse HTML
                   │
                   ▼
                  DOM

                 CSS
                   │
                   ▼
               Parse CSS
                   │
                   ▼
                 CSSOM

           DOM + CSSOM
                   │
                   ▼
              Render Tree
                   │
                   ▼
                Layout
          Size + Position
                   │
                   ▼
                 Paint
         Drawing Instructions
                   │
                   ▼
              Compositing
            Combine Layers
                   │
                   ▼
                 Pixels

What started as text has become something visible on a screen. And the process happens incredibly quickly.

Where JavaScript Enters the Picture

So far, we’ve mostly discussed HTML and CSS. But modern applications are highly dynamic. JavaScript constantly modifies the page.

Consider:

const card = document.querySelector(".card");

card.style.width = "600px";

Changing the width affects geometry. The browser may need to perform:

JavaScript
    │
    ▼
DOM / Style Change
    │
    ▼
Layout
    │
    ▼
Paint
    │
    ▼
Composite

Now consider:

card.style.backgroundColor = "red";

The geometry hasn’t changed. The card remains exactly where it was. The browser may therefore avoid layout and perform only the later rendering stages.

Conceptually:

JavaScript
    │
    ▼
Style Change
    │
    ▼
Paint
    │
    ▼
Composite

And for some composited animations:

card.style.transform = "translateX(100px)";

the browser may be able to perform primarily compositing work rather than recalculating the entire layout.

Conceptually:

JavaScript
    │
    ▼
Transform
    │
    ▼
Composite

The exact behavior depends on the browser and page, so these diagrams should be treated as useful mental models rather than rigid guarantees. But they reveal an important principle:

Not every visual change costs the browser the same amount of work.

Why This Matters for Frontend Developers

It’s easy to treat browser performance as something only framework authors need to worry about. But your everyday decisions influence this pipeline. When you manipulate the DOM thousands of times, you’re interacting with it. When you animate dimensions, you’re interacting with it. When you ship enormous stylesheets, you’re interacting with it. When you build deeply nested layouts, you’re interacting with it. When you repeatedly read layout information and immediately modify styles, you’re interacting with it.

Frameworks don’t eliminate the browser rendering pipeline. React still ends up modifying the DOM. Vue still ends up modifying the DOM. Angular still ends up modifying the DOM. Svelte still ends up modifying the DOM. Eventually, every web framework reaches the same destination:

Framework

   │

   ▼

DOM Changes

   │

   ▼

Browser Rendering Pipeline

   │

   ▼

Pixels

Understanding the browser therefore gives you knowledge that survives whichever framework becomes popular next.

A Practical Example

Imagine you’re building an animation. You write:

function move() {
    element.style.left =
        `${element.offsetLeft + 1}px`;

    requestAnimationFrame(move);
}

move();

Every frame, the code reads offsetLeft and then changes left. The browser may need layout information to answer the read, and the subsequent write can invalidate layout again. On a simple page, you may never notice. On a large application with hundreds or thousands of elements, repeated layout work can become expensive.

Now consider an animation using transforms:

let position = 0;

function move() {
    position += 1;

    element.style.transform =
        `translateX(${position}px)`;

    requestAnimationFrame(move);
}

move();

This gives the browser more opportunity to handle the animation efficiently through compositing.

Again, the point isn’t:

“transform is magically fast.”

The important lesson is understanding why some changes can require less work from the rendering pipeline than others. Once you understand that, frontend optimization becomes reasoning rather than memorization.

The Browser Has a Frame Budget

Smooth interfaces usually aim for approximately 60 frames per second on a 60 Hz display. That gives the browser roughly:

1000ms / 60 ≈ 16.7ms

to produce each frame.

Within that small window, the browser may need to:

JavaScript

↓

Style Calculation

↓

Layout

↓

Paint

↓

Composite

↓

Display Frame

If the work takes significantly longer than the available frame time, the browser may miss a frame. Users experience that as:

Jank
Stuttering
Delayed interactions
Choppy animations
An interface that simply feels slow

This is why a page can load quickly and still feel terrible to use. Performance isn’t only about how quickly resources download. It’s also about how efficiently the browser can respond to changes after the page has loaded.

Common Rendering Performance Mistakes

Understanding the pipeline makes several common frontend mistakes easier to recognize. One is changing layout properties continuously during animations. Another is performing large numbers of DOM operations individually when they could be grouped together. Developers can also accidentally force repeated layout calculations by alternating between reading geometry and modifying styles. Large and unnecessary visual effects can make painting more expensive. Creating too many compositing layers can consume additional memory rather than improving performance.

And perhaps most importantly, developers sometimes optimize based on rules they’ve memorized instead of measuring what the browser is actually doing. Modern browser developer tools can show you layout work, painting, long tasks, frame timings, and other performance information. Use them.

The rendering pipeline gives you the mental model. Profiling tells you what your particular application is actually doing.

Bringing It All Together

When you write:

<button>Buy Now</button>

the browser does far more work than the simplicity of that line suggests. It parses the HTML. It constructs the DOM. It processes CSS and builds the CSSOM. It determines which elements need to participate in rendering. It calculates their dimensions and positions. It generates painting instructions. It organizes visual content into layers where appropriate. Finally, it composites everything into the pixels you see on your screen.

HTML ──────► DOM
               │
               │
CSS ───────► CSSOM
               │
               ▼
          Render Tree
               │
               ▼
            Layout
               │
               ▼
             Paint
               │
               ▼
          Compositing
               │
               ▼
             Pixels

And whenever your application changes the page, parts of that process may happen again. That’s why understanding browser rendering is so useful. It transforms frontend performance from a collection of mysterious rules into something you can reason about.

Final Thoughts

Frontend development is often taught from the framework downward. Learn React. Learn Vue. Learn Angular. Learn Next.js. Those tools are useful, but underneath every one of them sits the browser.

The browser doesn’t know that your application uses React. It doesn’t care whether your state came from Redux, Zustand, Pinia, signals, or a server component. Eventually, something needs to become HTML, styles, layout, drawing instructions, and pixels.

Understanding that journey gives you a foundation that isn’t tied to any particular framework. The next time an animation stutters, a page becomes sluggish after a DOM update, or a seemingly harmless CSS change causes unexpected performance problems, you’ll have a much better question to ask than:

“Why is the browser slow?”

You can ask:

“Which part of the rendering pipeline am I forcing the browser to repeat?”

And that’s a much more useful question.

What’s Next?

We’ve seen how the browser transforms HTML and CSS into pixels. But we also discovered something interesting along the way. Changing certain properties can force the browser to calculate layout again. Other changes may require repainting. Some animations can avoid much of that work and happen primarily during compositing.

So what exactly makes one visual update more expensive than another?

That’s where we’ll go next in Beyond the UI:

Reflow and Repaint Explained: Why Some UI Updates Are Expensive

We’ll explore what actually happens when the DOM changes, how layout thrashing occurs, why certain CSS properties are more expensive to animate, and how to build interfaces that remain smooth even as they become more complex.

Event-Driven Architecture Explained: Building Systems That React to Events

Billy Okeyo — Fri, 31 Jul 2026 00:00:00 +0000

“The most scalable systems don’t constantly ask what’s happening. They simply react when something happens.”

Imagine you’re building an online marketplace. A customer places an order. At first, the workflow seems straightforward. The application creates the order, charges the customer’s card, reserves inventory, schedules shipment, sends a confirmation email, updates analytics, awards loyalty points, and notifies the warehouse. A traditional implementation might have the Order Service call each of these services directly.

Order Service

     │

     ├── Payment Service

     ├── Inventory Service

     ├── Shipping Service

     ├── Email Service

     ├── Analytics Service

     └── Loyalty Service

At first, this architecture feels perfectly reasonable. Each service performs its work and returns a response. As the business grows, however, the Order Service slowly becomes responsible for more and more integrations. Marketing introduces a Recommendation Service, finance adds an Accounting Service, customer success wants a CRM integration, and fraud detection joins the platform. Before long, every new feature requires modifying the Order Service. A service that originally knew only how to create orders now knows almost everything about the entire company. The result is tight coupling. Every new integration increases complexity, every downstream outage affects the original request, and every deployment becomes slightly more risky.

Eventually, developers begin asking a different question. Instead of asking:

“Which services should I call?”

They begin asking:

“What happened?”

That small change in thinking fundamentally changes the architecture. Instead of directly calling every interested service, the Order Service simply announces:

“An order has been created.”

It doesn’t care who listens and doesn’t even know who listens. It simply publishes an event, and every interested service reacts independently. The Shipping Service prepares delivery, the Email Service sends a confirmation, analytics records another sale, loyalty awards points, fraud detection evaluates the transaction, and recommendation engines update customer preferences. The Order Service never calls any of them directly.

This architectural style is known as Event-Driven Architecture (EDA). Instead of services communicating through tightly coupled request-response interactions, they communicate through events describing things that have already happened. This shift may seem subtle, but in reality, it completely changes how distributed systems evolve, scale, and recover from failure.

What Is an Event?

Before discussing Event-Driven Architecture, it’s important to understand what an event actually is. An event is simply a record that something meaningful has already happened. It is not something that might happen, and not something another service should do, but something that has already occurred. Examples include:

Order Created
Payment Completed
Customer Registered
Loan Approved
Inventory Reserved
Shipment Delivered

Notice the wording: every event is written in the past tense because events describe facts. Once an event has occurred, it becomes part of the system’s history. Unlike commands, events don’t tell another service what to do. They simply communicate what has already happened. This distinction is incredibly important. Consider the difference between these two messages.

Command

Charge Customer

Event

Customer Charged

The first message expects another service to perform work; the second informs the rest of the system that the work has already been completed. Commands ask; events announce. That simple distinction lies at the heart of Event-Driven Architecture.

How Event-Driven Systems Work

Imagine a borrower submits a loan application. The Loan Service validates the request, stores the application, and commits its transaction. Rather than directly calling every downstream service, it publishes a LoanApplicationSubmitted event, and from there every interested service works independently.

Loan Service

      │

LoanApplicationSubmitted

      │

──────── Event Broker ────────

      │

      ├── Risk Service

      ├── Notification Service

      ├── Fraud Detection

      ├── CRM

      └── Analytics

Notice what changed: the Loan Service no longer knows anything about these downstream systems. Adding another consumer doesn’t require modifying the Loan Service, and removing one doesn’t either. Every service simply subscribes to the events it cares about. That loose coupling is one of the defining advantages of Event-Driven Architecture.

Why This Improves Scalability

Suppose your application suddenly doubles in size. Marketing introduces three new services, operations introduces two more, and finance adds another. In a request-response architecture, every one of those integrations often requires modifying the originating service. In an event-driven architecture, nothing changes. The new services simply subscribe to existing events, and the publisher remains exactly the same. This dramatically reduces coupling and allows applications to evolve much more independently. Instead of building systems that know about one another, you’re building systems that share facts. That distinction becomes increasingly valuable as applications grow.

Event Brokers: The Backbone of Event-Driven Systems

At this point, a natural question arises. If services no longer call one another directly, how do events actually travel through the system? The answer is an event broker. An event broker acts as the central communication hub for your architecture. Instead of sending events directly to every interested service, a publisher sends the event to the broker, and the broker becomes responsible for delivering it to every subscriber. Conceptually, the architecture looks like this:

                Order Service

                     │

      OrderCreated Event

                     │

                     ▼

             Event Broker

     ┌─────────┼─────────┐

     ▼         ▼         ▼

 Inventory   Shipping   Analytics

   Service    Service     Service

Notice what has disappeared: the Order Service no longer knows how many consumers exist, doesn’t know whether the Analytics Service is online, and doesn’t know whether another team introduces a Recommendation Service next month. Its only responsibility is publishing the event. Everything else becomes someone else’s concern. Several technologies can act as event brokers. Apache Kafka is widely used for high-throughput event streaming. RabbitMQ is popular for traditional message queuing. Cloud platforms offer managed services such as Amazon EventBridge, Amazon SQS, Azure Service Bus, and Google Pub/Sub. Each has different strengths, but they all serve the same purpose: moving events from producers to consumers without tightly coupling the two.

Why Event-Driven Architecture Matters

At first glance, publishing events instead of calling APIs might not seem like a revolutionary change. In practice, however, it fundamentally changes how software evolves. Consider our online marketplace again. The Order Service publishes an OrderCreated event. Initially, only three services consume it.

Shipping
Email
Inventory

A year later, the business introduces:

Fraud Detection
Recommendation Engine
Customer Rewards
CRM Integration
Business Intelligence
Machine Learning

The Order Service doesn’t change. It continues publishing exactly the same event, and the new services simply subscribe. This is one of the greatest strengths of Event-Driven Architecture: applications grow by adding consumers rather than modifying existing publishers, which greatly reduces the ripple effect of change.

The Trade-Offs

Like every architectural style, Event-Driven Architecture solves some problems while introducing others. One important difference is that communication becomes asynchronous. When a customer places an order, the application may respond immediately even though several downstream services are still processing events. This improves responsiveness but introduces eventual consistency.

For a short period, different services may have slightly different views of the system. The order may already exist while the reporting dashboard hasn’t yet been updated, or the shipment may still be pending while the payment has already completed. This isn’t necessarily a problem; it’s simply a different consistency model, and applications must be designed with that reality in mind. Debugging also becomes more challenging. In a request-response architecture, tracing a workflow often means following a sequence of API calls. In an event-driven architecture, the workflow is distributed across many independent services reacting to events at different times, so good observability becomes essential. Correlation IDs, distributed tracing, structured logging, and monitoring tools become increasingly valuable as systems grow.

Common Mistakes

One of the biggest mistakes teams make is publishing events for everything. Not every database update deserves an event. Good events represent meaningful business occurrences. Examples include:

Customer Registered
Order Completed
Loan Approved
Payment Received

Poor events often expose internal implementation details. Examples include:

CustomerTableUpdated
RowModified
AddressFieldChanged

Consumers should care about business facts, not database implementation. Another common mistake is assuming events are delivered exactly once. In reality, duplicates can occur, messages can be delayed, and consumers can retry. This is why patterns we’ve already explored, such as Idempotency, remain critically important. Reliable event-driven systems assume events may be delivered more than once and design consumers accordingly. Finally, avoid replacing every API with events. Not every interaction should be asynchronous. Some operations naturally require an immediate response. For example:

User authentication
Payment authorization
Real-time validation

A healthy architecture often combines synchronous APIs with asynchronous events, using each where it makes the most sense.

Request-Response vs Event-Driven

A useful way to compare these architectures is to think about who controls the conversation.

In a request-response system, one service explicitly asks another service to perform work, and the caller waits for an answer before continuing. In an event-driven system, a service simply announces what has already happened. Anyone interested may react, and anyone uninterested simply ignores the event. Neither architecture is universally better. Request-response communication is often simpler and easier to understand, while event-driven communication provides greater flexibility and scalability as systems become more complex. Most modern applications use both. User-facing requests frequently begin as synchronous API calls, and once the business transaction completes, the application publishes events that allow the rest of the system to react independently.

How Everything Fits Together

If you’ve followed this series from the beginning, you’ve probably noticed a pattern. Each article answered a question created by the previous one.

Concept	Question It Answers
Idempotency	What if the same request arrives twice?
Race Conditions	What if multiple requests modify the same data?
Database Transactions	How do I keep related database operations atomic?
Isolation Levels	What should concurrent transactions be allowed to see?
Distributed Locks	How do multiple application instances coordinate work?
Outbox Pattern	How do I reliably publish events after committing data?
Saga Pattern	How do multiple services complete one business process?
CQRS	Should reads and writes use the same model?
Event-Driven Architecture	How do independent services communicate and evolve together?

Notice that none of these patterns exists in isolation. An event-driven application might use:

Idempotency to safely handle duplicate events.
Transactions to protect local database operations.
The Outbox Pattern to reliably publish domain events.
Saga Pattern to coordinate long-running business workflows.
CQRS to optimize read and write workloads independently.
Distributed Locks where multiple application instances must coordinate exclusive work.

The real power doesn’t come from mastering one pattern. It comes from understanding how they complement one another.

Final Thoughts

Software architecture isn’t about collecting design patterns. It’s about solving real problems with the right level of complexity. Event-Driven Architecture has become popular because it reflects how modern organizations grow. Teams become independent. Services evolve at different speeds. New features appear continuously. Direct dependencies become increasingly expensive to maintain. By allowing services to communicate through events rather than tightly coupled API calls, Event-Driven Architecture enables systems that are more flexible, more scalable, and more resilient to change. Like every pattern we’ve explored, however, it isn’t a silver bullet. Small applications may never need an event broker, and a well-designed monolith may outperform a poorly designed event-driven system. Architecture should always follow business needs, not trends. The goal isn’t to build the most sophisticated system possible. It’s to build the simplest system capable of solving today’s problem while leaving room for tomorrow’s growth.

Beyond CRUD: Chapter One Complete

When we began this series, we started with a deceptively simple question:

What happens if the same request arrives twice?

From there, we explored race conditions, transactions, concurrency, distributed coordination, reliable messaging, long-running workflows, scalable read models, and event-driven communication. Each article introduced a new piece of the puzzle, and together they form a foundation for understanding how modern backend systems remain reliable under retries, failures, concurrency, and scale.

If there’s one lesson to carry forward, it’s this:

Reliable software isn’t built by avoiding failure. It’s built by expecting failure, understanding where it can occur, and designing systems that recover gracefully when it does.

That mindset, more than any single framework, language, or database, is what separates production-ready systems from code that only works under perfect conditions. The journey beyond CRUD doesn’t end here. It begins here.

CQRS Explained: Separating Reads and Writes for Scalable Systems

Billy Okeyo — Mon, 27 Jul 2026 00:00:00 +0000

“The way you write data isn’t always the best way to read it.”

Imagine you’re building an online marketplace. Every day, thousands of customers browse products, place orders, track deliveries, and review their purchase history. At the same time, administrators manage inventory, warehouse staff update shipments, finance teams generate reports, and recommendation engines continuously analyze customer behavior.

From a user’s perspective, everything appears seamless. Behind the scenes, however, the application is performing two fundamentally different kinds of work. Some requests are changing data: a customer places an order, an administrator updates inventory, a payment is processed, or a shipment is marked as delivered. Other requests simply read data: customers search for products, managers open dashboards, support agents review order histories, and executives generate monthly reports.

At first, it’s tempting to handle both using the same database tables and the same application models. After all, an order is an order. Whether you’re creating it or displaying it, why shouldn’t the same model work for both? For many applications, that’s exactly what happens. The same entity is used for inserting records, updating records, validating business rules, and serving data to the user interface.

As applications grow, however, this approach begins to reveal its limitations. The information required to create an order is often very different from the information required to display one. Creating an order might require validating inventory, calculating taxes, applying discounts, verifying payment details, and enforcing business rules. Displaying an order, on the other hand, may require customer information, shipping updates, product images, payment status, warehouse progress, and delivery estimates, all combined into a single view optimized for the user.

Trying to satisfy both responsibilities with one model often leads to increasingly complicated code. The write model becomes cluttered with fields needed only for reporting, the read model becomes constrained by rules that exist only for data modification, queries grow more complex, performance begins to suffer, and developers start adding workarounds that make the system harder to maintain.

Eventually, an important realization emerges.

The way we write data isn’t necessarily the best way to read it.

That simple observation led to a pattern known as Command Query Responsibility Segregation, more commonly called CQRS. Rather than forcing one model to satisfy two very different responsibilities, CQRS separates them completely. Commands become responsible for changing data, queries become responsible for reading data, and each side can then evolve independently, optimized for its own purpose. Before exploring how CQRS works, let’s first understand why combining reads and writes into the same model eventually becomes a problem.

Why One Model Eventually Becomes a Problem

When most applications begin, life is simple. Suppose you’re building a loan management platform. A borrower submits a loan application. The application validates the input, saves the record, and later retrieves the same information whenever a loan officer opens the application. The same model handles both writing and reading.

LoanApplication

Everything works perfectly. As the platform grows, however, different users begin asking for different views of the same information. A loan officer wants to see repayment history, guarantors, collateral, risk score, and supporting documents on one screen; finance wants reports showing outstanding balances grouped by branch; executives want dashboards displaying portfolio performance; and customers simply want to know whether their application has been approved.

Notice what’s happening: everyone is looking at the same business entity, but nobody wants exactly the same data. To satisfy these different requirements, the application gradually starts joining more tables.

Loan

JOIN Customer

JOIN Branch

JOIN RiskAssessment

JOIN LoanOfficer

JOIN Repayments

JOIN Documents

JOIN Guarantors

The queries become larger, response times increase, and the code becomes harder to maintain. Ironically, the information required to display a loan has become far more complicated than the information required to create one. This is where many systems begin struggling. The write model keeps accumulating fields that only reports need, the read model becomes constrained by business rules that only matter during updates, and eventually one model is trying to solve two completely different problems.

Commands and Queries Are Different

One of the core ideas behind CQRS is recognizing that not every request has the same purpose. Some requests change data; others simply read it. These are fundamentally different operations. A command tells the system to perform an action. For example:

Create Order
Approve Loan
Reserve Inventory
Charge Payment
Register Customer

Commands represent intent. They usually contain business validation, enforce rules, and modify application state. A query, on the other hand, doesn’t change anything. Its only responsibility is returning information. For example:

Get Customer Profile
List Outstanding Loans
View Order History
Search Products
Display Dashboard

Queries don’t perform business logic. They answer questions. This distinction may seem small, but in reality, it changes how applications are designed.

What Is CQRS?

CQRS stands for Command Query Responsibility Segregation. Despite the intimidating name, the underlying idea is surprisingly simple. Instead of using one model for everything, CQRS separates the write side from the read side. Commands become responsible for modifying data, and queries become responsible for retrieving it. Conceptually, the architecture looks like this.

                Application

                     │

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

      │                             │

   Commands                     Queries

      │                             │

Write Model                  Read Model

      │                             │

Database                 Optimized View

The important thing to notice is that the read model no longer has to look like the write model. Each side is free to evolve independently.

The Write Model

The write model exists to protect business rules. Suppose a customer places an order. The application needs to verify inventory, calculate discounts, validate payment, reserve stock, and create the order. All of those steps belong on the write side. The write model isn’t concerned with how information will later appear on a dashboard. Its only responsibility is ensuring the business operation is correct. Think of it as the gatekeeper for your data. Nothing enters the system without passing through the write model.

The Read Model

The read model has a completely different job. Its responsibility isn’t enforcing business rules, it’s returning information as efficiently as possible. Imagine displaying an order summary. The customer expects to see:

Order number
Customer name
Product images
Shipping status
Payment status
Delivery estimate
Total price

The write model probably stores all of this across multiple tables, but the read model doesn’t have to. Instead, it can store exactly the shape required by the user interface, so instead of executing six joins every time someone opens an order, the read model may already contain everything in one place.

This dramatically simplifies queries while improving performance.

Why This Improves Performance

Suppose an online store receives ten thousand requests every minute. Only five hundred of those requests create or update orders. The remaining nine thousand five hundred simply display information. Traditional CRUD applications often force both workloads through the same models and database structures. CQRS recognizes that reads and writes have completely different characteristics. Reads are usually far more frequent, while writes are usually more complicated. By separating them, each side can be optimized independently: the write model focuses on correctness, the read model focuses on speed, and neither compromises the other.

A Real-World Example

Think about YouTube. Uploading a video and watching a video are two completely different operations. Uploading requires validation, virus scanning, metadata extraction, thumbnail generation, transcoding, and storage. Watching a video requires none of those things. The viewer simply wants the video to start playing immediately. Trying to optimize both operations using exactly the same model would make little sense.

CQRS applies the same principle to business applications. The model responsible for creating data doesn’t have to be the same model responsible for presenting it. Recognizing that difference is the first step toward understanding why CQRS has become such a popular architectural pattern in modern backend systems.

At this point, we’ve separated reads from writes conceptually. The next question naturally follows:

If the read model and write model are separate, how do they stay synchronized?

Keeping the Read Model Up to Date

One of the first questions developers ask after learning about CQRS is:

“If my read model is separate from my write model, how does it stay up to date?”

The answer depends on the architecture, but in most modern systems, the read model is updated using events.

Suppose a customer places an order. The write model validates the request, checks inventory, processes payment, and commits the transaction. Once the transaction succeeds, an event such as OrderCreated is published, and one or more components responsible for maintaining the read model receive that event and update their own optimized view of the data.

Conceptually, the flow looks like this:

Customer

      │

      ▼

Command

(Create Order)

      │

      ▼

Write Model

      │

      ▼

Database

      │

      ▼

OrderCreated Event

      │

      ▼

Read Model Updated

      │

      ▼

User Queries Data

Notice something important: the user’s query never touches the write model. Instead, it reads from a model specifically designed for displaying information.

Eventual Consistency

Because the read model is updated after the write completes, there is usually a short delay before the latest information becomes visible. This is known as eventual consistency. Imagine placing an order on a large e-commerce platform. The checkout page immediately confirms that your purchase was successful, but if you refresh your order history a fraction of a second later, the new order might not appear immediately. A moment later, it does. Nothing is wrong: the write completed instantly, and the read model simply needed a short amount of time to catch up. For many applications, this tiny delay is perfectly acceptable. Users rarely notice a difference measured in milliseconds or even a few seconds, and the benefit is that reads become dramatically faster and easier to scale.

Does CQRS Require Microservices?

One of the biggest misconceptions about CQRS is that it only works in microservice architectures. It doesn’t. CQRS is simply a design pattern. A single monolithic application can separate its command handlers from its query handlers just as effectively as a distributed system. Likewise, CQRS doesn’t require Kafka, RabbitMQ, Event Sourcing, or multiple databases. Many applications implement CQRS using a single database while maintaining separate command and query models inside the same application. As systems grow, those models may eventually evolve into separate databases or services, but that’s a scaling decision, not a requirement of the pattern itself.

When Should You Use CQRS?

CQRS isn’t a solution to every problem. Many applications work perfectly well using traditional CRUD architecture. If your application has simple business rules, relatively small datasets, and straightforward queries, introducing CQRS often adds unnecessary complexity. On the other hand, CQRS becomes increasingly valuable when reads and writes have very different characteristics. Common examples include:

High-traffic e-commerce platforms.
Banking and financial systems.
Loan management platforms.
Logistics and supply chain applications.
Reporting and analytics dashboards.
SaaS products with complex administrative views.

In these systems, the information required to display data is often very different from the information required to modify it. Separating those responsibilities makes the application easier to optimize and easier to maintain.

CQRS vs Traditional CRUD

A useful way to understand CQRS is to compare it with the architecture most developers already know.

Traditional CRUD	CQRS
One model for reads and writes	Separate models for reads and writes
Simpler to build	More flexible at scale
Easier for small systems	Better suited for complex domains
Queries often become increasingly complex	Read models are optimized for specific use cases
Business rules and presentation concerns frequently mix together	Responsibilities remain clearly separated

Neither approach is universally better. CRUD is an excellent choice for many applications. CQRS becomes valuable when the complexity of the domain begins to outweigh the simplicity of using a single model.

Common Mistakes

One mistake developers frequently make is adopting CQRS simply because they’ve heard it’s a “best practice.” Like every architectural pattern, CQRS introduces additional moving parts. You’ll often have separate models, additional event handling, and the possibility of eventual consistency. If those complexities don’t solve a real business problem, they’re simply unnecessary overhead. Another common mistake is trying to create one read model that satisfies every possible screen. The real strength of CQRS lies in allowing each query to have a model optimized for its own purpose. A customer dashboard, an administrative report, and a mobile application may each deserve different read models. Finally, don’t confuse CQRS with Event Sourcing. Although the two patterns are often used together, they solve different problems. CQRS separates reads from writes, while Event Sourcing stores state as a sequence of events. You can implement one without the other.

Bringing It All Together

Throughout this series, we’ve gradually built a collection of patterns that solve different reliability and scalability challenges.

Concept	Question It Answers
Idempotency	What if the same request arrives twice?
Race Conditions	What if multiple requests modify the same data simultaneously?
Database Transactions	How do I keep database operations atomic?
Isolation Levels	What should concurrent transactions be allowed to see?
Distributed Locks	How do multiple application instances coordinate work?
Outbox Pattern	How do I reliably publish events after committing data?
Saga Pattern	How do multiple services complete one business process reliably?
CQRS	Should the same model be responsible for both reading and writing data?

Notice how the series has gradually expanded in scope. We began by making individual API requests reliable, then learned how to coordinate transactions, communicate between services, and manage distributed business workflows. CQRS adds another important lesson: sometimes the best way to scale an application isn’t by making one model do everything, but by giving different responsibilities to different models.

Final Thoughts

One of the biggest lessons in software architecture is that different problems deserve different solutions. Reading data and writing data may involve the same business entity, but they rarely have the same requirements. Writes prioritize correctness, validation, and enforcing business rules; reads prioritize speed, simplicity, and delivering information in the shape users actually need. CQRS embraces this difference instead of trying to hide it. For small applications, a traditional CRUD architecture is often the right choice. As systems become larger and business requirements become more demanding, separating reads from writes can lead to simpler queries, clearer responsibilities, and applications that scale far more gracefully. Like every pattern we’ve explored in the Beyond CRUD series, CQRS isn’t about making software more complicated. It’s about choosing the right level of complexity to solve the problem in front of you.

What’s Next?

So far, we’ve explored several patterns that improve reliability, scalability, and maintainability. One question still remains: how do all these patterns fit together to build applications where services communicate entirely through events instead of direct API calls?

In the next article, we’ll explore Event-Driven Architecture Explained: Building Systems That React to Events, where we’ll connect concepts like the Outbox Pattern, Saga Pattern, and CQRS into a cohesive architectural style used by many modern distributed systems.

Saga Pattern Explained: Managing Distributed Transactions Across Microservices

Billy Okeyo — Fri, 24 Jul 2026 00:00:00 +0000

“A transaction can roll back one database. A Saga coordinates many databases that have never even met.”

Imagine you’re building an online marketplace. A customer clicks Place Order, expecting what feels like a single operation. Behind the scenes, however, that simple button sets off a chain of events involving several independent services. The Order Service creates a new order, the Inventory Service reserves the purchased items, the Payment Service charges the customer’s card, the Shipping Service schedules delivery, and the Notification Service sends a confirmation email.

From the customer’s perspective, it’s one transaction. From your system’s perspective, it’s anything but. Each service owns its own database, each commits its own transaction independently, none of them has direct control over the others, and no single database transaction can span all of them.

Now imagine the following sequence: the Order Service successfully creates the order, the Inventory Service reserves the last laptop in stock, and the Payment Service charges the customer’s credit card. Then, just as the Shipping Service begins preparing the shipment, it discovers that delivery isn’t available to the customer’s location. The order already exists, the customer’s card has already been charged, and inventory has already been reserved, but the shipment can never be created. Unlike a traditional database transaction, there is no single ROLLBACK command capable of undoing work performed across multiple independent databases.

This is one of the defining challenges of distributed systems. As applications evolve from monoliths into microservices, business processes increasingly span services that are independently deployed, independently scaled, and independently owned. While this architecture offers tremendous flexibility, it also introduces a difficult question:

How do you maintain business consistency when a workflow spans multiple services and one of them fails halfway through?

The answer is not a larger transaction. It’s a different way of thinking. Instead of trying to make every service commit simultaneously, modern distributed systems break long-running business processes into a sequence of smaller local transactions. If every step succeeds, the workflow completes successfully. If a step fails, previously completed work is undone using carefully designed compensating actions rather than database rollbacks.

This approach is known as the Saga Pattern. Like the Outbox Pattern, the Saga Pattern embraces the reality that failures are inevitable. Rather than pretending distributed transactions behave like local database transactions, it provides a practical way to recover when things don’t go according to plan. Before we explore how Sagas work, it’s important to understand why traditional transactions stop working once your application crosses service boundaries.

Why Database Transactions Don’t Scale Across Microservices

Earlier in this series, we explored database transactions and learned how they guarantee that multiple operations either succeed together or fail together. If an online banking application deducts money from one account and credits another within the same database, a transaction ensures that both operations are treated as a single unit of work. If anything fails before the transaction commits, every change is rolled back automatically, leaving the database in a consistent state.

That model works beautifully when everything happens inside one database, but microservices change the picture completely. Imagine an order workflow involving four independent services.

Customer

      │

      ▼

Order Service

      │

      ▼

Inventory Service

      │

      ▼

Payment Service

      │

      ▼

Shipping Service

Each service owns its own database. The Order Service cannot directly roll back changes made by the Payment Service, the Payment Service cannot undo inventory reservations, and the Shipping Service has no authority over the Order database. Every service commits its own transaction independently. This independence is one of the greatest strengths of microservices, and it’s also one of their biggest challenges. Suppose the workflow progresses like this:

Create Order ✅

↓

Reserve Inventory ✅

↓

Charge Payment ✅

↓

Create Shipment ❌

At this point, three services have already committed their work, and nothing can simply “roll back.” Unlike a single database transaction, there is no global undo button. This challenge is often referred to as a distributed transaction, and solving it using traditional database techniques quickly becomes impractical.

Years ago, distributed systems experimented with approaches such as Two-Phase Commit (2PC), where every participating system agreed to either commit or roll back together. While theoretically elegant, 2PC introduced significant coordination overhead, reduced availability, increased latency, and created situations where entire systems could become blocked waiting for slow or unavailable participants. Modern cloud-native architectures generally avoid this approach. Instead of attempting to make every service commit simultaneously, they accept that each service commits independently and focus on coordinating the overall business process.

That’s exactly what the Saga Pattern does. Instead of one large transaction, a Saga is a sequence of smaller transactions linked together by business logic. If every step succeeds, the Saga completes successfully; if one step fails, previously completed steps are compensated through additional business actions designed to reverse their effects. That distinction is subtle but incredibly important: a Saga doesn’t roll back database transactions, it performs new transactions whose purpose is to restore the system to a valid business state. Understanding that difference is the key to understanding everything else about the Saga Pattern.

Understanding Compensating Transactions

One of the biggest misconceptions developers have when they first encounter the Saga Pattern is assuming it somehow provides a distributed version of ROLLBACK. It doesn’t, and in fact, that’s one of the defining characteristics of a Saga. Once a service commits its local transaction, that transaction is permanent. The database has already saved the changes, and there is no mechanism for another service to rewind history. Instead of rolling back completed work, a Saga performs compensating transactions. A compensating transaction is simply another business operation whose purpose is to undo the effects of a previous one.

Suppose an order has already been created, inventory has been reserved, and payment has been successfully processed. If shipping later fails because the customer’s address falls outside the delivery area, the system cannot ask every database to roll back, because those transactions finished long ago. Instead, the application performs a series of new operations: the payment service issues a refund, the inventory service releases the reserved stock, and the order service changes the order status from Pending to Cancelled.

Notice something important: nothing has been deleted and nothing has been rolled back. The system simply performs additional work that restores the business to a valid state.

Conceptually, the workflow now looks like this:

Create Order ✅

↓

Reserve Inventory ✅

↓

Charge Payment ✅

↓

Create Shipment ❌

↓

Refund Payment

↓

Release Inventory

↓

Cancel Order

This is the heart of the Saga Pattern. Rather than pretending failures never happened, the system accepts them and responds with carefully designed business actions. This approach is much more realistic because, in distributed systems, failures aren’t exceptional, they’re inevitable.

A Banking Example

Imagine a customer applies for a personal loan. Several independent services participate in the approval process: the Loan Service creates the application, the Credit Service performs a credit check, the Risk Service evaluates affordability, and the Notification Service informs the customer of the decision. Everything proceeds normally until the Risk Service determines that the customer’s debt-to-income ratio exceeds the organization’s lending policy. At this point, the application cannot continue. If this were a single database transaction, we would simply issue a rollback.

In a microservice architecture, however, the Loan Service has already committed the new application and the Credit Service has already stored the completed credit assessment. Neither service can magically erase its work because another service encountered a problem. Instead, the Saga performs compensating actions: the Loan Service marks the application as withdrawn, the Credit Service archives its assessment, and the Notification Service informs the customer that the application could not proceed. Each action is itself a normal transaction, and collectively they restore the overall business process to a consistent state.

Rollback vs Compensation

Although these ideas sound similar, they’re fundamentally different. A database rollback behaves like this:

BEGIN

↓

Update Balance

↓

Insert Payment

↓

Failure

↓

ROLLBACK

When the rollback occurs, the database behaves as though none of the changes ever happened. It’s as if the transaction never existed. A Saga works very differently.

Reserve Inventory

↓

Charge Payment

↓

Shipment Fails

↓

Refund Payment

↓

Release Inventory

The original payment really happened, the refund also really happened, and both become part of the permanent history of the system. That’s an important distinction, and many business domains actually require this behavior. Consider financial systems. Deleting payment records would make auditing impossible, so recording both the payment and the subsequent refund creates a complete, traceable history of what occurred. Compensation isn’t about pretending mistakes never happened, it’s about correcting them transparently.

Designing Good Compensating Actions

Writing a compensating transaction isn’t simply a matter of reversing database changes. You’re reversing business operations. For example, suppose a hotel booking system reserves a room.

The compensating action isn’t:

Delete reservation row.

It’s:

Release the room back into available inventory.

Similarly, if an airline charges a customer’s credit card, the compensation isn’t:

Delete payment record.

It’s:

Create a refund transaction.

This distinction matters because business systems are usually audited. Historical events should remain visible, and what changes is the current business state. Whenever you design a Saga, a useful question to ask is:

“If this step succeeds but a later step fails, what business action restores the system to a valid state?”

Thinking in terms of business operations rather than database updates leads to much more reliable designs.

Every Step Is Independent

Another characteristic of Sagas is that every step represents a complete, independent transaction. Suppose an order workflow consists of four services.

Order Service

↓

Inventory Service

↓

Payment Service

↓

Shipping Service

Each service commits its own database transaction before the next service begins, which means failures are isolated. If the Shipping Service experiences an outage, it doesn’t corrupt the Payment Service’s database; likewise, if the Payment Service fails, it doesn’t leave the Inventory Service with an unfinished SQL transaction.

Each service remains responsible for its own data, and the Saga simply coordinates how those independent pieces fit together. This separation of responsibility is one of the reasons microservice architectures scale so well. Services remain loosely coupled while still participating in larger business workflows.

Thinking in Business Processes

One of the biggest mindset shifts when working with Sagas is realizing that you’re no longer designing database transactions. You’re designing business processes. Database transactions answer questions like:

“How do I keep these SQL statements consistent?”

Sagas answer a much broader question:

“How does my business recover when part of this workflow succeeds and another part fails?”

That’s why Sagas often involve business concepts rather than technical ones: refunds, reservation cancellations, order cancellations, inventory releases, and account reversals. These aren’t database operations; they’re business operations that happen to involve databases. Once you begin thinking at that level, the Saga Pattern becomes much easier to understand because it mirrors how real businesses operate. Companies don’t erase history when something goes wrong, they perform additional actions to correct it, and software simply follows the same principle.

Two Ways to Coordinate a Saga

Now that we understand what a Saga is, another important question emerges: Who is responsible for coordinating all these steps?

Imagine once again that a customer places an order. The Order Service creates the order, the Inventory Service reserves the stock, the Payment Service charges the customer, and the Shipping Service prepares the shipment. If everything succeeds, the Saga completes; if one step fails, compensating transactions begin. Someone, or something, must decide what happens next.

There are two common ways to achieve this coordination:

Choreography
Orchestration

Both accomplish the same goal, but they do so in very different ways.

Choreography

Think about a group of experienced dancers performing together. Nobody stands at the front giving instructions. Each dancer knows exactly when to move because they respond to the music and to one another. Saga choreography works in much the same way. Instead of a central coordinator directing every step, each service reacts to events published by other services. Consider our order workflow.

Customer Places Order

        │

        ▼

Order Service

Publishes

OrderCreated

        │

        ▼

Inventory Service

Publishes

InventoryReserved

        │

        ▼

Payment Service

Publishes

PaymentCompleted

        │

        ▼

Shipping Service

Publishes

ShipmentCreated

Every service only knows two things:

The events it listens for.
The events it publishes.

The Payment Service doesn’t know the Shipping Service exists, and the Shipping Service doesn’t know anything about the Inventory Service. Each service simply reacts whenever an event arrives. This loose coupling is one of choreography’s greatest strengths. Because services know very little about one another, adding or removing services often becomes much easier.

Suppose your business introduces a Loyalty Service that awards reward points whenever an order is completed. Nothing else needs to change. The new service simply subscribes to the PaymentCompleted event, and the rest of the system continues operating exactly as before. This flexibility makes choreography extremely attractive in event-driven architectures. However, it comes with a cost. As systems grow, understanding the overall business workflow becomes increasingly difficult. Instead of one visible process, the Saga becomes scattered across many services.

To understand why a shipment wasn’t created, you may need to inspect logs from the Order Service, Inventory Service, Payment Service, Shipping Service, and Notification Service. The workflow still exists, it’s simply distributed across the entire system.

Orchestration

Now imagine the same dancers performing with a conductor standing at the front. Instead of reacting to one another, every performer follows instructions from a single leader. This is orchestration. Rather than allowing services to coordinate themselves, a dedicated component, often called the Saga Orchestrator, controls the entire workflow. The orchestrator tells each service what to do next.

Saga Orchestrator

        │

        ▼

Create Order

        │

        ▼

Reserve Inventory

        │

        ▼

Charge Payment

        │

        ▼

Create Shipment

If every step succeeds, the orchestrator declares the Saga complete. If a failure occurs, it explicitly instructs previous services to execute their compensating transactions.

Shipment Failed

        │

        ▼

Refund Payment

        │

        ▼

Release Inventory

        │

        ▼

Cancel Order

Unlike choreography, every decision is visible in one place. Need to understand the business process? Read the orchestrator. Need to change the workflow? Modify one component instead of updating several independent services. This centralized view makes orchestration particularly appealing for complex business processes involving many steps, conditional logic, or approval workflows. The trade-off, however, is tighter coupling. The orchestrator must understand every participating service, making it more aware of the overall system than any individual service would be in a choreographed Saga. Neither approach is universally better. The right choice depends on the complexity of the workflow and the level of control your application requires.

Choreography vs Orchestration

A useful way to compare them is to think about where the business logic lives. With choreography, the workflow is distributed across many services, and every service contributes a small piece of the overall process by responding to events. With orchestration, the workflow lives inside a single coordinator that explicitly directs every participant.

Choreography	Orchestration
Event-driven	Command-driven
Highly decoupled	Central coordinator
Easy to extend	Easy to understand
Workflow spread across services	Workflow visible in one place
Can become difficult to trace	Coordinator becomes more complex

Small event-driven systems often benefit from choreography because new consumers can easily subscribe to existing events. Larger enterprise workflows frequently choose orchestration because business rules remain easier to understand and maintain.

Real-World Examples

By now, you’ve probably encountered situations where the Saga Pattern would be useful without realizing it. An online retailer processing orders, a loan management platform approving applications, an airline booking system reserving flights, or a hotel reservation platform coordinating room availability all involve multiple independent services participating in a single business process. Consider a digital lending platform. When a borrower accepts a loan offer, several services may participate:

The Loan Service creates the loan account.
The Disbursement Service sends funds.
The Accounting Service records journal entries.
The Notification Service sends an SMS.
The Credit Bureau Service updates the borrower’s status.

If the disbursement fails because the customer’s bank account is invalid, the system shouldn’t leave behind a partially created loan. Instead, compensating actions mark the loan as cancelled, reverse accounting entries where necessary, and notify the customer that disbursement was unsuccessful. No database rollback spans all these services, and the Saga restores business consistency through coordinated business actions.

Common Mistakes

The Saga Pattern is powerful, but it’s not a silver bullet. One common mistake is trying to treat compensating transactions as database rollbacks. They aren’t. Compensation should reverse business effects, not erase history. Another mistake is making Saga steps too large. Every local transaction should remain focused and complete quickly. Long-running database transactions reduce scalability and increase the likelihood of contention. It’s also important to remember that messaging is rarely perfect. Duplicate events, delayed delivery, and retries are normal in distributed systems. Every participating service should therefore be designed with idempotency in mind. Finally, don’t introduce a Saga simply because your application uses microservices. If a workflow only involves one service and one database, a normal database transaction is usually the simpler and better solution. Sagas solve distributed coordination problems, not ordinary CRUD operations.

Saga Pattern vs Traditional Transactions

At first glance, Sagas and database transactions appear to solve similar problems. In reality, they operate at completely different levels. A database transaction guarantees consistency within a single database; a Saga guarantees business consistency across multiple independent services. One relies on rollback, the other relies on compensation. One typically completes in milliseconds, while the other may run for several minutes, or even hours, depending on the business process. They’re not competing approaches. As you’ve seen throughout this series, they complement one another. In fact, a single Saga step usually contains its own local database transaction.

Bringing It All Together

At this point in the Beyond CRUD series, we’ve gradually built a toolkit for designing reliable backend systems. Each concept answers a different engineering question.

Concept	Question It Answers
Idempotency	What if the same request arrives twice?
Race Conditions	What if multiple requests modify the same data simultaneously?
Database Transactions	How do I keep multiple database operations atomic?
Isolation Levels	What should concurrent transactions be allowed to see?
Distributed Locks	How do multiple application instances coordinate shared work?
Outbox Pattern	How do I reliably publish events after committing data?
Saga Pattern	How do multiple services complete one business process reliably?

Notice how every concept builds upon the previous one. None replaces the others, and reliable distributed systems emerge when these patterns work together.

Final Thoughts

Building software inside a single database is relatively straightforward. Building software that spans dozens of independent services is something else entirely. The challenge isn’t simply writing correct code, it’s ensuring that business processes continue making sense even when networks fail, services restart, or one step succeeds while another doesn’t.

The Saga Pattern embraces these realities rather than fighting them. Instead of relying on one enormous transaction that spans every service, it coordinates many smaller transactions while providing a structured way to recover when failures occur. That mindset has become one of the defining characteristics of modern cloud-native architecture. As your systems continue growing, you’ll discover that reliable software isn’t built by eliminating failures, it’s built by designing systems that expect failures and know exactly how to recover from them.

What’s Next?

So far, we’ve focused primarily on making writes reliable, but as applications grow, another challenge begins to emerge. Reading data efficiently often requires very different models from writing it. Should the same model be responsible for both, or should we optimize reads and writes independently?

In the next article, we’ll explore CQRS Explained: Separating Reads and Writes for Scalable Systems, a pattern that allows applications to scale, simplify complex queries, and build richer user experiences without overloading their write models.

The Outbox Pattern Explained: Publishing Events Without Losing Data

Billy Okeyo — Mon, 20 Jul 2026 00:00:00 +0000

“A database transaction can guarantee your data is correct. It cannot guarantee the rest of your system knows about it.”

Imagine you’re building an e-commerce platform. A customer places an order, and your application begins processing the request. Inside a database transaction, it creates the order, deducts the purchased items from inventory, records the payment, and commits the transaction successfully. From the perspective of the database, everything has gone exactly as planned. Every change has been saved, every business rule has been respected, and the transaction completes without error.

If this were a monolithic application, the story might end there, but modern software rarely consists of a single application. The moment an order is created, several other systems need to react. A shipping service must prepare the package, an email service needs to send an order confirmation, an analytics platform wants to record another sale, a loyalty service may award reward points, and an accounting system might need to generate journal entries. Rather than constantly querying the orders table looking for changes, these services usually rely on events published through a message broker such as Kafka, RabbitMQ, Azure Service Bus, or Amazon SQS.

A straightforward implementation seems almost obvious: once the transaction commits successfully, publish an OrderCreated event.

BEGIN TRANSACTION

↓

Create Order

↓

Reduce Inventory

↓

Record Payment

↓

COMMIT

↓

Publish OrderCreated Event

At first glance, there’s nothing wrong with this approach, until something fails. Suppose the database transaction commits successfully, permanently saving the customer’s order. A fraction of a second later, however, Kafka becomes temporarily unavailable. Perhaps RabbitMQ disconnects, or maybe the application crashes before it can publish the event.

The order now exists in the database, the customer’s payment has been processed, and inventory has already been reduced, yet none of the downstream services know the purchase ever happened. The warehouse never receives instructions to prepare the shipment, the customer never receives a confirmation email, the analytics dashboard quietly reports incorrect sales figures, and the accounting system never records the transaction.

Nothing inside the database is inconsistent. The inconsistency exists between systems.

This subtle failure is one of the most common reliability problems in distributed architectures. It’s known as the Dual-Write Problem, and it’s surprisingly easy to introduce because writing to a database and publishing an event are two completely independent operations. One can succeed while the other fails, leaving different parts of the system with different versions of reality.

In our previous articles, we’ve explored how transactions protect database operations, how isolation levels govern concurrent access to data, and how distributed locks coordinate work across multiple application servers. The Outbox Pattern builds on those concepts by solving a different challenge: ensuring that once your database commits a change, the rest of your system will eventually learn about it as well.

Before we look at the solution, let’s first understand why this seemingly simple problem is much harder than it appears.

The Dual-Write Problem

The Dual-Write Problem occurs whenever an application attempts to update two independent systems as part of a single business operation. One system is usually your database; the other is typically a message broker, search index, cache, analytics platform, or another external service. Although these updates feel like one logical operation, they are technically two completely separate actions.

Consider an online banking application. When a customer transfers money, the application updates account balances inside the database. Afterward, it publishes a MoneyTransferred event so other services can respond. A fraud detection system may inspect the transaction, a notification service may send an SMS, and an accounting platform may update its ledgers.

Conceptually, all of this represents one business event, but technically, it looks more like this:

Update Database

↓

Publish Event

The problem is that neither system knows anything about the other. Your database has no idea whether Kafka accepted the message, and Kafka has no knowledge of whether your SQL transaction committed successfully. They’re completely independent, and that independence creates four possible outcomes.

Database	Event	Result
✅ Success	✅ Success	Everything works correctly.
❌ Failure	❌ Failure	Nothing happens, which is acceptable.
❌ Failure	✅ Success	Downstream systems react to an event for data that doesn’t exist.
✅ Success	❌ Failure	The database is correct, but no other service knows the change occurred.

The first two outcomes are easy to reason about, but it’s the final two that create serious problems. If an event is published for data that never commits, downstream services begin processing information that doesn’t actually exist. Equally dangerous is the opposite scenario, where the database commits successfully but the event is never published. From that moment onward, every service in the architecture has a different understanding of reality. This isn’t merely an inconvenience; it’s a consistency problem that becomes increasingly difficult to detect as systems grow.

Why Transactions Can’t Solve This

A natural question follows: why not simply include the message broker inside the database transaction? Unfortunately, that’s not how database transactions work. Transactions provide atomicity because every operation is coordinated by the same database engine. The database controls when the transaction begins, when it commits, and when it rolls back. Every SQL statement participates in that process because they’re all executed by the same system.

A message broker lives outside that boundary. Kafka doesn’t participate in your PostgreSQL transaction, RabbitMQ doesn’t know your SQL Server transaction exists, and PostgreSQL has no mechanism for asking Kafka whether a message was published successfully before committing the transaction. In other words, there is no shared transaction manager coordinating both systems.

Years ago, technologies such as Two-Phase Commit (2PC) attempted to solve this problem by coordinating transactions across multiple systems. Although theoretically appealing, they introduced significant complexity, increased latency, reduced availability, and often became bottlenecks in distributed environments.

As microservices became more popular, the industry gradually moved toward simpler, more resilient approaches. Rather than trying to make two systems commit simultaneously, engineers began asking a different question:

What if we only committed to one system first and made the second system eventually consistent?

That shift in thinking led to one of the most influential patterns in modern backend architecture: the Outbox Pattern.

What Is the Outbox Pattern?

The Outbox Pattern solves the Dual-Write Problem by changing the order in which work is performed. Instead of attempting to update the database and publish an event as part of the same operation, the application first commits everything it needs to the database, including the event itself. That last part is the key. Rather than sending the event directly to Kafka or RabbitMQ, the application writes the event into a dedicated database table commonly known as the outbox.

Because the business data and the outbox record are written inside the same database transaction, they succeed or fail together. If the transaction commits, both the business data and the event are safely stored; if it rolls back, neither exists. Only after the transaction has completed does another process read events from the outbox table and publish them to the message broker.

Conceptually, the workflow changes from this:

Update Database

↓

Publish Event

to this:

BEGIN TRANSACTION

↓

Update Business Data

↓

Insert Event Into Outbox

↓

COMMIT

↓

Background Publisher Reads Outbox

↓

Publish Event

↓

Mark Event As Published

At first glance, this may seem like a small adjustment, but in reality, it completely changes the reliability characteristics of your application. The application is no longer trying to coordinate two independent systems within the same request. Instead, it commits to a single source of truth, the database, and lets another process handle communication with external systems afterward. If the message broker is temporarily unavailable, nothing is lost. The event is already safely stored inside the database and simply waits until the publisher can deliver it.

Understanding the Outbox Table

The outbox itself is usually nothing more than a normal database table. A simplified version might look like this:

id	event_type	payload	created_at	published_at
1	OrderCreated	{…}	2026-07-01 10:15	NULL
2	PaymentReceived	{…}	2026-07-01 10:16	NULL
3	UserRegistered	{…}	2026-07-01 10:18	2026-07-01 10:18

Each row represents an event that should eventually be delivered. Notice the published_at column: rows where this value is NULL haven’t yet been published, while rows with a timestamp have already been successfully delivered.

The outbox isn’t intended to become a permanent event store. Instead, it acts as a reliable staging area between your transactional database and your messaging infrastructure. Once an event has been published successfully, and your retention policy allows, it can be archived or deleted.

A Complete Walkthrough

Let’s revisit our e-commerce example. A customer purchases a laptop. Inside a single transaction, the application performs three operations: first, it creates the order; second, it deducts one item from inventory; and finally, instead of publishing an event immediately, it inserts a new row into the outbox table describing what happened.

BEGIN TRANSACTION

↓

INSERT Order

↓

UPDATE Inventory

↓

INSERT Outbox Event

↓

COMMIT

At this point, the customer’s purchase has been committed successfully, and just as importantly, the event describing that purchase has also been committed. Suppose Kafka goes offline immediately afterward: the request still succeeds, nothing has been lost, and the application doesn’t need to roll back the order because the event hasn’t disappeared. It is sitting safely inside the outbox table waiting to be delivered.

A separate publisher service periodically checks the outbox. When Kafka becomes available again, it publishes the event and updates the record to indicate that delivery succeeded.

Outbox Publisher

↓

Read Unpublished Events

↓

Publish To Kafka

↓

Success?

      │

   Yes │ No

      │

Mark Published

      │

Retry Later

Notice something important: the user’s request is no longer responsible for talking to Kafka. Its only responsibility is ensuring that the event is safely recorded, and publishing becomes a separate concern. That separation dramatically improves reliability because temporary failures in external systems no longer affect the original business transaction.

Why This Works

The elegance of the Outbox Pattern comes from the fact that it reduces a distributed systems problem to a database problem. Earlier in this series, we spent considerable time discussing transactions and learned that they guarantee a group of related database operations either all succeed or all fail together. The Outbox Pattern deliberately takes advantage of that guarantee: instead of asking a database and a message broker to commit simultaneously, a task they were never designed to perform, it asks only the database to commit. Since both the business data and the outbox record live inside the same database, the transaction naturally guarantees their consistency.

Everything after that becomes a delivery problem rather than a consistency problem. Even if the publisher crashes, Kafka becomes unavailable, or the network experiences intermittent failures, the event remains safely stored. The publisher will eventually retry, and the event will eventually be delivered. The system moves from requiring immediate consistency between the database and the message broker to achieving eventual consistency in a reliable and predictable way. That single shift in mindset is what has made the Outbox Pattern one of the most widely adopted reliability patterns in modern distributed systems.

Why Not Publish Immediately After the Commit?

Some developers look at the Outbox Pattern and ask a reasonable question: “If the transaction has already committed successfully, why not simply publish the event right afterward and retry if it fails?” The problem is that retries only work if the application survives long enough to perform them.

Imagine the following sequence of events:

COMMIT Transaction

↓

Application Crashes

↓

Restart

The order exists, the event was never published, and the application has no memory that it still owes Kafka an event because that information was never persisted anywhere. With an outbox table, the event survives the crash because it was committed alongside the business data. When the publisher starts again, it simply resumes reading unpublished events from the database. The application doesn’t have to remember what happened because the database already does.

This is one of the reasons the Outbox Pattern is so resilient. It relies on durable storage rather than application memory, making it naturally tolerant of crashes, restarts, and temporary infrastructure failures.

How Events Leave the Outbox

By now, we’ve established that the application’s responsibility ends once the business data and the corresponding event have been committed to the database. The next challenge is equally important: How do those events actually reach Kafka, RabbitMQ, or another messaging system?

Broadly speaking, there are two common approaches. The first is a Polling Publisher, where a background worker periodically checks the outbox table for unpublished events. Every few seconds, or even every few milliseconds, it queries the database, publishes any pending events, and marks them as successfully delivered.

Conceptually, the process looks like this:

Background Publisher

↓

Query Outbox

↓

Find Unpublished Events

↓

Publish Event

↓

Success?

     │

 Yes │ No

     │

Mark Published

     │

Retry Later

This approach is simple to understand, easy to implement, and works well for many applications. Since the publisher operates independently of the original request, temporary failures in Kafka or RabbitMQ don’t affect users. If publishing fails, the worker simply retries later.

The second approach is Change Data Capture (CDC). Instead of periodically querying the outbox table, a CDC tool monitors the database’s transaction log and automatically detects newly inserted outbox records. As soon as a new event appears, the tool publishes it to the message broker.

One of the most popular CDC solutions is Debezium, which integrates with databases such as PostgreSQL, MySQL, and SQL Server. Rather than polling the database repeatedly, Debezium continuously streams database changes, reducing unnecessary queries while providing near real-time event publication. Both approaches solve the same problem. Polling is generally simpler and perfectly adequate for many systems, while CDC becomes attractive when applications process very large numbers of events or require lower publishing latency.

Real-World Examples

The Outbox Pattern appears in many more places than developers often realize. Once you begin recognizing the Dual-Write Problem, you start seeing it almost everywhere.

E-Commerce

A customer places an order. The transaction creates the order, updates inventory, and inserts an OrderCreated event into the outbox. Later, the publisher delivers that event to Kafka, and other services respond independently:

Shipping prepares the package.
Email sends the confirmation.
Analytics records the sale.
Loyalty awards points.

Every service receives exactly the same event without the original request needing to coordinate them.

Loan Management Systems

Suppose a borrower makes a repayment. Inside a transaction, the application updates the loan balance, records the payment, recalculates outstanding interest, and inserts a LoanRepaymentReceived event into the outbox. Once published, other systems can react independently. The accounting service posts journal entries, the notification service sends an SMS receipt, reporting dashboards update repayment statistics, and credit scoring services refresh customer profiles. The repayment itself remains fast because none of these downstream systems participate in the original transaction.

User Registration

A customer creates a new account. The application stores the user’s information and writes a UserRegistered event into the outbox. Later, other services consume the event. An email service sends a welcome message, a CRM platform creates a customer profile, a marketing system subscribes the user to onboarding campaigns, and a recommendation engine begins generating personalized suggestions. The registration endpoint doesn’t need to know anything about those systems; its only responsibility is recording that the registration occurred.

Payment Processing

Imagine a payment gateway confirms a successful transaction. The payment service updates account balances, records the payment, and inserts a PaymentCompleted event. Even if Kafka becomes unavailable immediately afterward, the payment itself isn’t lost. Once messaging resumes, the event is delivered and downstream systems continue exactly where they left off.

Benefits of the Outbox Pattern

One of the reasons the Outbox Pattern has become so widely adopted is that it solves several problems simultaneously. First, it provides reliability. Once an event has been written into the outbox, it becomes durable. Temporary network failures, message broker outages, or application crashes no longer result in permanently lost events. Second, it simplifies application code. Rather than forcing every request to coordinate database updates and message publication, the request focuses exclusively on committing business data, and event publication becomes the responsibility of a dedicated background process. Third, it improves scalability. Because event publication happens asynchronously, user requests complete more quickly, and slow downstream systems no longer delay the original transaction. Finally, it naturally embraces eventual consistency. Instead of requiring every service to update simultaneously, the system guarantees that every interested service will eventually receive the event once communication becomes available.

Common Mistakes

Like every architectural pattern, the Outbox Pattern can be implemented incorrectly.

One common mistake is assuming that publishing an event means the work is finished. Publishing only guarantees that the message reached the broker. Consumers may still fail, messages may still be retried, and downstream services must therefore remain resilient and, where appropriate, idempotent.

Another common mistake is forgetting to clean up the outbox table. If events remain forever, the table will continue growing until queries become unnecessarily expensive. Most production systems archive or remove published events after an appropriate retention period.

Developers also sometimes attempt to perform expensive business logic inside the publisher. The publisher should remain intentionally simple. Its responsibility is publishing events, not recalculating business rules or modifying application state.

Finally, don’t assume every database change requires an event. Publishing unnecessary events creates noise, increases infrastructure costs, and makes systems more difficult to understand. Good events represent meaningful business occurrences, not individual SQL statements.

Outbox Pattern vs Distributed Transactions

At first glance, the Outbox Pattern and distributed transactions appear to solve the same problem. Both attempt to coordinate work across multiple systems, but the difference lies in how they approach consistency. Distributed transactions attempt to make every participating system commit or roll back together. The Outbox Pattern accepts that this is often impractical in distributed architectures. Instead, it commits business data first and guarantees that events will eventually be delivered. This approach sacrifices immediate consistency in exchange for simplicity, resilience, and availability. For modern cloud-native applications, that trade-off is often the better engineering decision.

Outbox Pattern vs Event Sourcing

The Outbox Pattern is also frequently confused with Event Sourcing. Although both involve events, they solve entirely different problems. With the Outbox Pattern, the database remains the primary source of truth, and events simply communicate that something has happened. With Event Sourcing, events are the source of truth. Instead of storing the current state of an order or account, the system stores every event that led to its current state, and the application reconstructs state by replaying those events.

An outbox event might say:

Order Created.

An event-sourced system would permanently record every event throughout the order’s lifetime:

Order Created
Payment Authorized
Inventory Reserved
Shipment Prepared
Order Delivered

Both patterns involve events, but only Event Sourcing uses them to reconstruct application state.

Best Practices

If you’re considering adopting the Outbox Pattern, several practices consistently lead to reliable implementations.

Keep the outbox in the same database as your business data so that both participate in the same transaction.

Design your publisher to be idempotent wherever possible. Network failures and retries are inevitable, and duplicate publication attempts should never produce incorrect results.

Monitor the outbox table. A growing backlog of unpublished events is often the earliest warning sign that something is wrong with your messaging infrastructure.

Treat event schemas as part of your public contract. Once other services depend on them, changing them carelessly becomes just as risky as changing a public API.

Finally, remember that publishing an event doesn’t guarantee it has been processed. Downstream services should always be designed to handle retries, duplicates, and temporary failures gracefully.

Bringing It All Together

At this point in the series, we’ve explored several techniques for building reliable software systems. Each one addresses a different question.

Concept	Question It Answers
Idempotency	What if the same request is sent twice?
Race Conditions	What if multiple requests modify the same data simultaneously?
Database Transactions	What if part of my database operation fails?
Isolation Levels	What should concurrent transactions be allowed to see?
Distributed Locks	How do multiple servers coordinate work?
Outbox Pattern	How do I reliably notify other systems after committing data?

Notice the progression: the concepts don’t replace one another, they build upon one another. Modern backend systems are reliable precisely because they combine multiple patterns, each solving a different class of failure.

Final Thoughts

One of the defining characteristics of distributed systems is that communication eventually fails. Networks become unreliable, applications restart, and message brokers experience outages. Trying to eliminate these failures entirely is unrealistic.

The Outbox Pattern embraces this reality by changing the problem. Instead of attempting to guarantee that two independent systems succeed simultaneously, it guarantees that business data is safely committed first and that communication will eventually catch up. This seemingly small architectural decision dramatically improves reliability because it removes timing from the equation. Your application no longer depends on Kafka, RabbitMQ, or another messaging system being available at the exact moment a customer submits a request. Instead, it relies on something your database already does exceptionally well: storing data reliably.

The next time you find yourself writing code that updates a database and immediately publishes an event, pause for a moment and ask yourself:

“What happens if my database succeeds but my message broker doesn’t?”

If the answer is “my systems become inconsistent,” you’ve probably found a place where the Outbox Pattern belongs.

What’s Next?

So far in this series, we’ve focused on making individual operations reliable. But what happens when a single business process spans multiple microservices, each with its own database and transaction?

Imagine placing an order that requires the payment service, inventory service, shipping service, and notification service to all complete successfully. What happens if one of those services fails halfway through?

In the next article, we’ll explore the Saga Pattern, one of the most widely used approaches for coordinating long-running business transactions across distributed systems.

Distributed Locks Explained: Technologies That Implement Distributed Locks

Billy Okeyo — Fri, 17 Jul 2026 00:00:00 +0000

Now that we understand how distributed locks work conceptually, the next question becomes:

Where do these locks actually live?

Unlike database transactions, distributed locks cannot rely on the memory of a single application server. Remember, our application might be running on five, ten, or even hundreds of machines, and every server must consult the same source of truth before deciding whether it may perform a particular operation.

Over the years, several technologies have emerged to solve this coordination problem. Although they all provide distributed locking capabilities, they were designed with slightly different goals in mind. Let’s look at the most common ones.

Redis

For most web applications, Redis is by far the most popular choice. Originally designed as an in-memory data store, Redis is incredibly fast, making it an excellent candidate for lightweight coordination tasks.

Acquiring a lock in Redis is surprisingly straightforward. A server attempts to create a key using an atomic command that says, in effect:

“Create this key only if it doesn’t already exist.”

If Redis successfully creates the key, the server owns the lock; if the key already exists, another server is already performing the work. Because Redis executes this operation atomically, two servers can never successfully create the same lock at the same time.

A simplified example looks like this:

SET invoice-generation

Server-A

NX

EX 30

The command says:

Create the key only if it doesn’t already exist (NX).
Automatically expire it after thirty seconds (EX 30).

In one atomic operation, Redis both acquires the lock and ensures it won’t remain forever if the server crashes. For many applications, this is all that’s needed.

Why Redis Is So Popular

Redis has become the default choice for distributed locks because it satisfies three important requirements. First, it’s extremely fast: since Redis stores data in memory rather than on disk, lock acquisition usually takes only a few milliseconds. Second, many applications already use Redis for caching, sessions, queues, or rate limiting, so adding distributed locking often requires little additional infrastructure. Finally, Redis has mature client libraries for virtually every programming language, with Laravel, Django, Spring Boot, .NET, Node.js, and Go all providing excellent Redis support.

For the vast majority of business applications, Redis offers an excellent balance between simplicity, performance, and reliability.

The Challenge with a Single Redis Instance

Suppose your entire application depends on one Redis server. Everything works perfectly, then Redis crashes. Suddenly, no application server can acquire new locks, and even worse, if Redis loses its in-memory state during a restart, locks may disappear unexpectedly.

This introduces a new challenge: the coordinator itself has become a single point of failure. For many applications, this risk is acceptable. For others, particularly financial systems or globally distributed services, it isn’t. This challenge led to one of the most discussed topics in distributed systems: the Redlock algorithm.

The Redlock Algorithm

Redlock was proposed by Redis creator Salvatore Sanfilippo as a way to make Redis-based distributed locks more resilient. Instead of relying on one Redis server, Redlock uses multiple independent Redis instances.

Imagine five Redis servers.

Redis 1

Redis 2

Redis 3

Redis 4

Redis 5

When acquiring a lock, the application attempts to obtain it from all five servers, and the lock is considered successful only if a majority agree.

For example:

Acquire Lock

↓

Redis 1 ✅

Redis 2 ✅

Redis 3 ✅

Redis 4 ❌

Redis 5 ❌

Three out of five succeeded, so the application proceeds. If only two servers grant the lock, the operation fails because a majority wasn’t reached. This approach significantly reduces the impact of individual Redis failures.

However, Redlock is also one of the most debated algorithms in distributed systems. Some engineers argue that it’s sufficient for many practical systems, while others, including Martin Kleppmann, have published detailed critiques explaining situations where Redlock may not provide the guarantees developers expect. The important lesson isn’t that Redlock is good or bad; it’s that distributed systems involve trade-offs, and understanding those trade-offs matters more than memorizing algorithms.

ZooKeeper

Long before Redis became popular for distributed locking, many large distributed systems relied on Apache ZooKeeper. ZooKeeper was designed specifically for coordination. Rather than functioning as a cache, it provides services such as:

Distributed locks
Leader election
Configuration management
Service discovery

Think of ZooKeeper as a highly reliable coordinator for distributed applications. Its primary goal isn’t speed, it’s correctness. Large systems such as Apache Kafka, Hadoop, and HBase have historically relied on ZooKeeper to coordinate clusters of machines. If your application requires complex distributed coordination rather than simple locking, ZooKeeper remains an excellent choice.

etcd

If you’ve worked with Kubernetes, you’ve already encountered etcd, even if you didn’t realize it. Every Kubernetes cluster stores its configuration inside etcd. Like ZooKeeper, etcd is a distributed key-value store designed for coordination rather than caching. It provides:

Distributed locks
Leader election
Configuration storage
Consensus
Service coordination

Unlike Redis, etcd prioritizes consistency over raw performance. Its API is also designed around long-lived leases, making lock management particularly elegant. Modern cloud-native applications frequently choose etcd when they already operate within Kubernetes ecosystems.

Consul

HashiCorp Consul occupies a similar space. Although many developers know Consul for service discovery, it also provides distributed locking capabilities through sessions. Organizations using Consul often rely on it for:

Service registration
Health checks
Distributed configuration
Leader election
Distributed locks

Like ZooKeeper and etcd, Consul focuses on reliable coordination across distributed infrastructure.

Which Technology Should You Choose?

There isn’t a universal answer. Instead, the right choice depends on your application’s requirements. If you’re building a typical web application that already uses Redis, implementing distributed locks with Redis is usually the simplest and most practical solution. If you’re coordinating hundreds of services across a Kubernetes cluster, etcd may integrate more naturally with your infrastructure. If your organization already uses Consul or ZooKeeper for service coordination, leveraging those existing systems often makes more sense than introducing Redis solely for locking.

Choosing a technology isn’t just about features. It’s also about operational complexity, existing infrastructure, and the guarantees your business requires. The important thing to remember is this: distributed locks are a concept, while Redis, ZooKeeper, etcd, and Consul are simply different tools for implementing that concept. Understanding the underlying idea is far more valuable than becoming attached to a specific technology.

Do You Always Need a Distributed Lock?

Reading this article, it might be tempting to conclude that distributed locks are the solution to every concurrency problem. They’re not. In fact, many applications never need them. If your application runs on a single server, ordinary in-memory locks are often sufficient, and if your database transaction already guarantees correctness, introducing a distributed lock may simply add unnecessary complexity.

Distributed locks are powerful, but they should be introduced only when multiple independent application instances genuinely need to coordinate shared work. Like every distributed systems technique, they solve a very specific class of problems, and the best engineering decision is often knowing when not to use them.

Common Mistakes When Using Distributed Locks

Like many distributed systems concepts, distributed locks appear deceptively simple: acquire a lock, perform some work, release the lock. In practice, however, there are several subtle mistakes that can introduce bugs that are even harder to diagnose than the problem the lock was intended to solve. Understanding these pitfalls is just as important as understanding distributed locks themselves.

Assuming a Lock Lasts Forever

One of the most common mistakes is forgetting that distributed locks usually have an expiration time. Suppose a server acquires a lock with a TTL of thirty seconds, and the developer assumes the operation will always finish within that window. Months later, a new feature makes the operation take forty-five seconds. The lock expires while the first server is still working, another server acquires the same lock and begins executing the exact same task, and suddenly, duplicate work appears again.

Choosing an appropriate TTL, and renewing it for long-running tasks when necessary, is essential.

Forgetting to Release the Lock

Although expiration protects against permanent deadlocks, applications should still release locks as soon as the protected work finishes. Holding a lock longer than necessary reduces concurrency and delays other servers waiting to perform legitimate work.

A good rule is simple:

Hold the lock only for the work that genuinely requires exclusive access.

Everything else should happen outside the lock whenever possible.

Protecting Too Much Code

Developers sometimes wrap entire workflows inside a distributed lock. For example:

Acquire Lock

↓

Call External Payment API

↓

Generate PDF

↓

Upload File

↓

Send Email

↓

Release Lock

This means every other server waits while network requests, file generation, and email delivery are taking place. Often, only a small portion of the workflow actually requires exclusive access. A better approach is to keep the critical section as short as possible.

Acquire Lock

↓

Update Shared Resource

↓

Release Lock

↓

Generate PDF

↓

Send Email

The shorter the lock, the better the system scales.

Distributed Locks vs Database Locks

At first glance, distributed locks and database locks appear very similar. Both prevent concurrent operations and both coordinate access to shared resources, but they operate at completely different levels.

A database lock protects data inside the database. For example, when two transactions attempt to update the same customer record, the database can lock that row until one transaction completes. Everything happens within the database engine itself.

A distributed lock protects work performed by application servers. Instead of preventing two transactions from updating the same row, it prevents two application instances from starting the same business process. Consider generating monthly invoices: before any invoice rows even exist in the database, every server must first decide whether it should begin the job. That decision happens outside the database, and a distributed lock coordinates that decision.

An easy way to remember the difference is:

Database locks protect data. Distributed locks protect business operations.

In many systems, you’ll use both together. A distributed lock ensures only one server begins generating invoices, and database transactions then ensure every invoice is written consistently.

Distributed Locks vs Optimistic Concurrency

Another concept frequently confused with distributed locks is optimistic concurrency. Optimistic concurrency assumes conflicts are relatively rare. Instead of preventing multiple users from editing the same record, it detects whether someone else changed the data before saving.

Suppose two employees open the same customer profile, and each begins editing. The system stores a version number alongside the record. When Employee A saves, the version changes from 5 to 6. When Employee B later attempts to save, the application notices that the version has already changed. Rather than silently overwriting Employee A’s work, it rejects the update and asks Employee B to refresh the page. No locking was required; the conflict was simply detected before committing.

Distributed locks take a different approach. Instead of detecting conflicts afterward, they prevent conflicting work from starting in the first place. Neither technique is universally better: optimistic concurrency works well when conflicts are uncommon, while distributed locks work best when duplicate execution would be expensive or dangerous.

Best Practices

As with most distributed systems techniques, simplicity is your friend. If you’re considering introducing distributed locks into your application, the following guidelines will help you avoid many common problems.

Keep Critical Sections Small

Acquire the lock immediately before modifying shared resources, and release it immediately afterward. The less work performed while holding the lock, the better your system scales.

Always Use Lock Expiration

Servers crash, containers restart, and networks fail. Never assume your application will always release its lock correctly. Expiration protects the rest of the system from waiting forever.

Verify Lock Ownership

Before releasing a lock, ensure your application still owns it. Ownership checks prevent one server from accidentally deleting another server’s lock after an expiration or retry.

Design for Failure

Distributed systems should always assume that something will eventually fail. Ask yourself:

What happens if Redis becomes unavailable?
What happens if the server crashes?
What happens if the network partitions?
What happens if the lock expires unexpectedly?

Thinking through failure scenarios early often prevents painful production incidents later.

Combine Reliability Patterns

Distributed locks are rarely used in isolation. Production systems often combine multiple reliability techniques. For example:

Idempotency prevents duplicate requests.
Transactions guarantee atomic database updates.
Isolation Levels provide predictable views of data.
Distributed Locks coordinate multiple application servers.

Each technique solves a different problem. Together, they create systems that continue behaving correctly even under heavy load and unexpected failures.

Bringing It All Together

At this point in the series, we’ve explored several concepts that all contribute to building reliable backend systems. Each one addresses a different question.

Concept	Question It Answers
Idempotency	What if the same request is sent twice?
Race Conditions	What if multiple requests modify the same data simultaneously?
Database Transactions	What if part of my operation fails?
Isolation Levels	What should transactions be allowed to see while others are running?
Distributed Locks	How do multiple servers agree who should perform a task?

Notice how these concepts complement one another. None replaces the others; reliable systems are built by combining the right tools for the right problems.

Final Thoughts

As applications grow, the biggest challenges often aren’t writing business logic. They’re coordinating work across multiple users, multiple requests, multiple transactions, and eventually multiple servers.

Distributed locks exist because modern applications are no longer confined to a single machine. They’re deployed across clusters, containers, cloud regions, and worker nodes that all need to cooperate without constantly stepping on each other’s toes.

Like transactions and isolation levels, distributed locks aren’t something you’ll use for every feature. But when you do need them, they can be the difference between a system that behaves predictably and one that quietly creates duplicate invoices, repeated payments, or inconsistent business data.

The next time you design a background job, scheduled task, or critical workflow, ask yourself one simple question:

“What happens if two servers try to do this at exactly the same time?”

If the answer is “something bad,” you’ve probably found a place where a distributed lock belongs.

What’s Next?

We’ve now covered:

Contract Testing
Idempotency
Race Conditions
Database Transactions
Database Concurrency
Database Isolation Levels
Distributed Locks

So far, every concept has focused on keeping operations consistent while they’re happening. But there’s another challenge waiting. Imagine you’ve successfully updated your database inside a transaction and now need to publish an event to Kafka, RabbitMQ, or another message broker. What happens if the database commit succeeds, but publishing the event fails? Or worse, what if the event is published but the transaction rolls back?

This problem has caused countless production incidents in distributed systems. In the next article, we’ll explore The Outbox Pattern Explained: Publishing Events Without Losing Data, one of the most widely used patterns for ensuring your database and message broker stay in sync.

Distributed Locks Explained: Coordinating Work Across Multiple Servers

Billy Okeyo — Mon, 13 Jul 2026 00:00:00 +0000

“Database locks protect rows. Distributed locks protect systems.”

Imagine your application has been wildly successful. What started as a simple web application running on a single server now runs across multiple machines behind a load balancer. Requests are shared between application instances, background workers process jobs independently, and scheduled tasks run on every server.

From the outside, everything looks better than ever: pages load faster, traffic scales effortlessly, and users are happy. Then one morning, your finance department calls. Every customer has received four monthly invoices.

Nothing appears wrong with the code. The invoice generation job is scheduled to run once every month, so why did it execute four times? The answer is surprisingly simple: you now have four application servers. At midnight, every server woke up, checked the scheduler, and independently decided that it was responsible for generating invoices. From each server’s perspective, everything was perfectly correct; collectively, however, they created a costly mistake.

Now imagine a different scenario. Your payment gateway sends a webhook confirming a successful payment. The webhook is delivered to one of your load-balanced servers, but a retry occurs because the payment provider doesn’t receive a response quickly enough, so another server processes the same webhook. Both servers begin updating balances, both create accounting entries, and both generate receipts.

You’ve already learned how idempotency protects against duplicate requests and how transactions ensure database operations succeed together.

But neither of those concepts answers a new question:

How do multiple application servers agree that only one of them should perform a particular piece of work?

That problem is solved by distributed locks.

As applications grow beyond a single server, distributed locks become one of the most important coordination mechanisms in modern software engineering.

Why Database Locks Are No Longer Enough

Earlier in this series, we explored database transactions and row-level locking.

Suppose two transactions attempt to update the same bank account.

Using a statement such as:

SELECT *
FROM accounts
WHERE id = 1
FOR UPDATE;

the database ensures only one transaction can modify that row at a time.

This works beautifully because both transactions are coordinating through the same database.

Now consider a different problem.

Suppose you have four application servers running the exact same code, and each server has a scheduler responsible for calculating monthly loan interest. Midnight arrives, and every server starts the same scheduled job. None of them are updating the same database row immediately. Instead, they’re deciding whether to begin an entire business process. The database has nothing to lock yet, and by the time one server begins writing data, the others have already started processing. The result is duplicated work.

Database locks are excellent at protecting individual records, but they are not designed to coordinate entire applications spread across multiple machines. This is the gap distributed locks were created to fill.

What Is a Distributed Lock?

A distributed lock is a coordination mechanism that allows multiple independent servers to agree that only one of them may perform a particular operation at a given time. Instead of protecting a single database row, a distributed lock protects an entire business activity.

Imagine a conference room with a single key. Anyone can use the room, but only the person holding the key may enter, and everyone else must wait until the key is returned. A distributed lock works in much the same way: before performing an operation, a server first attempts to acquire the lock. If the lock is available, the server proceeds; if another server already owns the lock, the operation waits, retries, or exits.

The important point is that every server asks the same central authority for permission before beginning work. That authority might be Redis, ZooKeeper, etcd, or another distributed coordination system.

A Simple Example

Imagine four application servers.

        Load Balancer
              │
   ┌──────────┼──────────┐
   │          │          │
Server A   Server B   Server C
   │          │          │
        Server D

At midnight, each server checks whether it’s time to generate invoices.

Without a distributed lock:

Server A → Generate invoices ✅

Server B → Generate invoices ✅

Server C → Generate invoices ✅

Server D → Generate invoices ✅

Four executions, four invoices, and one very unhappy finance department.

With a distributed lock:

Server A → Acquire Lock ✅

Server B → Lock Exists

Server C → Lock Exists

Server D → Lock Exists

Only Server A proceeds, and everyone else exits. The invoices are generated exactly once.

Real-World Examples

Distributed locks appear in far more places than most developers realize. Whenever multiple application instances could accidentally perform the same work, a distributed lock becomes a potential solution.

Scheduled Jobs

Suppose your loan management platform calculates accrued interest every night at midnight. Without coordination, every application server performs the calculation independently, interest may be applied multiple times, and a distributed lock ensures exactly one server performs the calculation.

Payment Processing

Imagine receiving a payment webhook from M-Pesa. Network retries cause multiple servers to receive the same notification, and without coordination, several servers may attempt to update balances simultaneously. A distributed lock allows only one server to process the payment while the others simply exit.

Inventory Management

Only one laptop remains in stock, and two servers receive purchase requests simultaneously. Each attempts to reserve the item. Although transactions protect database consistency, a distributed lock can coordinate reservation workflows across multiple application instances before they even begin modifying inventory.

Sending Emails

Marketing decides to send a promotional email to one million subscribers, and your email scheduler is deployed across five worker nodes. Without coordination, every worker starts sending the campaign and customers receive the same email five times. With a distributed lock, only one worker initiates the campaign while the others remain idle.

Report Generation

Generating annual financial reports may take several minutes. Without coordination, multiple servers might begin generating the exact same report simultaneously, wasting CPU time and increasing database load. A distributed lock ensures only one report generation process is active.

When Should You Consider a Distributed Lock?

A useful rule of thumb is to ask yourself a simple question:

What would happen if two servers performed this operation at exactly the same time?

If the answer is:

Duplicate invoices
Duplicate payments
Duplicate notifications
Duplicate accounting entries
Duplicate interest calculations

then the operation is probably a candidate for a distributed lock.

Not every feature needs one. Most HTTP requests don’t, reading data doesn’t, and serving web pages doesn’t. Distributed locks are primarily useful for shared background work and critical business processes where duplicate execution would produce incorrect results.

Distributed Locks Are About Coordination

One misconception worth addressing early is that distributed locks replace database transactions.

They don’t. Transactions guarantee consistency inside the database; distributed locks coordinate between application servers. The two solve different problems.

In practice, many enterprise systems use both together. A server first acquires a distributed lock, then begins a database transaction. When the transaction completes successfully, the server releases the distributed lock. The lock ensures only one server performs the work, and the transaction ensures the database remains consistent while that work is being performed. Together, they provide a powerful foundation for building reliable distributed systems.

At this point, we’ve answered why distributed locks exist.

The next question is equally important:

How do multiple servers actually agree on who owns the lock?

How Distributed Locks Work

At a high level, every distributed lock follows the same basic workflow.

Before performing a critical operation, an application asks a shared coordination service for permission to proceed. If the lock is available, the application acquires it and begins its work; if another server already owns the lock, the application waits, retries later, or simply exits. Once the work has been completed, the lock is released, allowing another server to acquire it.

Although different technologies implement this process differently, the underlying idea remains remarkably simple.

Application Server

        │

Request Lock

        │

───────────────
 Lock Service
───────────────

Lock Available?

   │          │

  Yes         No

   │          │

Acquire      Wait / Retry / Exit

   │

Perform Work

   │

Release Lock

The important detail is that every application instance talks to the same lock service. Without a shared source of truth, each server would simply believe it owned the lock.

Acquiring a Lock

Imagine four servers attempting to generate monthly invoices.

Each server sends a request to Redis asking for a lock called:

invoice-generation

Redis receives the requests almost simultaneously. The first request succeeds, and Redis stores something similar to:

invoice-generation

Owner: Server A

Expires: 30 seconds

When the remaining servers ask for the same lock, Redis responds that the lock already exists. Only Server A continues. Servers B, C, and D either wait, retry after a short delay, or abandon the operation altogether.

The beauty of distributed locks lies in their simplicity: instead of every server making its own decision, they all trust a single coordinator.

Holding the Lock

Once a server has successfully acquired the lock, it proceeds with the protected operation.

This might involve:

Generating invoices.
Processing a payment.
Calculating loan interest.
Sending reminder emails.
Synchronizing inventory.

During this period, every other server attempting the same operation sees that the lock is already owned. Rather than performing duplicate work, those servers simply back off. The lock effectively becomes a reservation saying that someone is already doing this work and others should wait.

Releasing the Lock

When the protected work completes successfully, the server releases the lock.

Acquire Lock

↓

Process Work

↓

Release Lock

Once Redis removes the lock, another server is free to acquire it if necessary. Releasing the lock is just as important as acquiring it. A lock that is never released eventually blocks every future attempt to perform that operation.

The Problem with Permanent Locks

Now consider something less pleasant.

Server A acquires the invoice-generation lock, but halfway through generating invoices, the server crashes. Perhaps the machine loses power, perhaps Kubernetes terminates the container, or perhaps someone accidentally restarts the application. The important point is that Server A never gets the opportunity to release its lock.

If the lock remained permanent, every future invoice generation attempt would fail because the system would forever believe Server A still owned the lock. This is one of the biggest differences between traditional application locks and distributed locks: distributed systems must always assume that servers can disappear without warning.

Lock Expiration (TTL)

To solve this problem, distributed locks almost always include an expiration time, often called a Time-To-Live (TTL).

Instead of storing only the lock name, the lock service stores something like:

Lock:

invoice-generation

Owner:

Server A

Expires:

30 seconds

If Server A completes successfully, it releases the lock before those thirty seconds expire. If Server A crashes, Redis automatically deletes the lock after the TTL expires, allowing another server to continue the work instead of waiting forever.

Think of it like borrowing a meeting room: rather than reserving it indefinitely, your booking automatically expires after one hour. If you forget to leave, the reservation eventually disappears and someone else can use the room. TTL prevents abandoned locks from permanently blocking the system.

Choosing the Right TTL

Choosing a lock duration isn’t as straightforward as it might seem.

Suppose generating invoices normally takes ten seconds, and a thirty-second TTL provides plenty of room for occasional delays. But what if one month the process unexpectedly takes forty-five seconds? The lock expires after thirty seconds, another server acquires it, and now both servers are generating invoices simultaneously. You’ve accidentally recreated the very problem the lock was supposed to prevent.

On the other hand, choosing an extremely long TTL isn’t ideal either. If a server crashes while holding a lock that expires after thirty minutes, every other server must wait half an hour before continuing. Finding the right TTL therefore requires understanding how long your operation normally takes, while leaving enough room for occasional delays.

Some distributed lock implementations even allow servers to periodically renew the TTL while they’re still actively working. This approach, often called a heartbeat, keeps long-running operations alive without requiring excessively long expiration times.

What Happens If Two Servers Ask at the Same Time?

One question naturally arises: what happens if two servers request the lock at exactly the same millisecond? The answer depends on the lock service.

Redis, ZooKeeper, etcd, and similar systems perform lock acquisition atomically. That means checking whether the lock exists and creating it happen as a single indivisible operation. There is never a moment when both servers successfully acquire the same lock: one request succeeds and the other fails. This atomicity is exactly what makes distributed locks reliable; without it, two servers could both believe they owned the lock, defeating the entire purpose.

Lock Ownership Matters

Imagine Server A acquires a lock. Before finishing its work, the lock expires because the TTL was too short, and Server B now acquires the same lock. Moments later, Server A finally finishes and attempts to release it. If the lock service simply deleted the lock without checking ownership, Server A would accidentally remove Server B’s lock, Server C could now acquire it, and suddenly two servers are working simultaneously again.

To prevent this, distributed lock implementations associate every lock with a unique owner identifier. When releasing a lock, the application must prove that it is still the owner; if ownership has already changed, the release request is ignored. This simple verification prevents one server from accidentally deleting another server’s lock.

Distributed Locks Aren’t Magic

It’s important to understand that distributed locks don’t eliminate failures. Servers can still crash, networks can still become partitioned, and Redis instances can still fail. Distributed locks simply provide a coordinated way for multiple application instances to make decisions despite those realities. They reduce duplicate work, improve consistency, and coordinate critical business operations, but like every distributed systems technique, they must be implemented carefully and combined with other reliability mechanisms such as transactions, retries, idempotency, and monitoring.

In the next section, we’ll explore the most common technologies used to implement distributed locks, including Redis, Redlock, ZooKeeper, etcd, and Consul, along with the strengths and weaknesses of each approach.

Database Isolation Levels Explained: Choosing the Right Consistency Guarantees

Billy Okeyo — Fri, 10 Jul 2026 00:00:00 +0000

Understanding the Four SQL Isolation Levels

Now that we’ve seen the kinds of problems concurrent transactions can create, the next question is obvious:

How does a database prevent them?

The answer lies in isolation levels.

Rather than enforcing a single set of rules for every application, relational databases allow developers to choose how isolated transactions should be from one another.

This flexibility exists because different applications have different priorities.

A banking application transferring millions of shillings every day values consistency above almost everything else.

A reporting dashboard displaying website traffic may prefer speed over perfect accuracy.

Isolation levels allow the database to balance these competing requirements.

As isolation becomes stronger, transactions observe more consistent data, but the database also has to coordinate more aggressively, often reducing concurrency.

As isolation becomes weaker, transactions execute more freely, improving performance but increasing the likelihood of observing changing data.

The SQL standard defines four isolation levels.

Each one builds upon the guarantees of the previous level.

Read Uncommitted

Read Uncommitted is the weakest isolation level defined by the SQL standard.

At this level, transactions are allowed to read changes made by other transactions even if those changes haven’t yet been committed.

Returning to our banking example, imagine Alice begins transferring KES 20,000 to another account.

The database deducts the money from her balance but hasn’t yet committed the transaction.

Another transaction immediately reads Alice’s account.

Instead of seeing KES 50,000, it now sees KES 30,000, even though the transfer could still fail and be rolled back.

That second transaction has just performed a dirty read.

The advantage of Read Uncommitted is that transactions almost never wait for one another.

Because the database performs very little coordination, throughput can be extremely high.

The downside is that applications may make decisions using data that never officially existed.

For most business applications, this is unacceptable.

Imagine calculating payroll using salaries that are eventually rolled back or approving a loan based on a balance that disappears moments later.

Fortunately, very few modern relational databases actually encourage Read Uncommitted.

Many databases either discourage it entirely or internally behave more conservatively even when it’s requested.

In practice, you’ll rarely choose this isolation level for production systems.

Read Committed

Read Committed is the default isolation level in databases such as PostgreSQL, Oracle, and SQL Server.

Instead of allowing transactions to read uncommitted changes, the database only exposes data that has already been committed.

This immediately eliminates dirty reads.

Returning to Alice’s transfer, suppose another transaction checks her balance while the transfer is still running.

Instead of seeing the temporary balance of KES 30,000, it continues seeing the previously committed balance of KES 50,000 until the transfer completes.

Only after the transaction commits does the new balance become visible.

This makes Read Committed an excellent general-purpose isolation level.

Applications never observe incomplete work, while the database still allows a high degree of concurrency.

However, Read Committed doesn’t solve every problem.

Suppose your transaction reads Alice’s balance at the beginning of a report.

A few seconds later, another transaction deposits KES 100,000 into the account and commits.

If your report queries the balance again before finishing, you’ll now see a different value.

The same row has changed during your transaction.

Read Committed prevents dirty reads, but it still allows non-repeatable reads and phantom reads.

For many applications, that’s a perfectly acceptable trade-off.

Read Committed Timeline

Transaction A                     Transaction B

BEGIN

Read Balance = 50,000

                               BEGIN

                               Deposit 100,000

                               COMMIT

Read Balance = 150,000

COMMIT

Both values are valid.

The important difference is that Transaction A never sees incomplete or rolled-back data.

It only observes committed changes.

Repeatable Read

Suppose you’re generating an end-of-day financial report.

Your transaction calculates the total account balance across thousands of customers.

Halfway through generating the report, another transaction updates several account balances.

If your report re-reads those accounts later, the totals may no longer match the values used earlier in the report.

This is exactly the situation Repeatable Read was designed to solve.

At this isolation level, once a transaction reads a row, subsequent reads of that same row always return the same version for the lifetime of the transaction.

Even if another transaction updates the row and commits, your transaction continues working with the original version.

It’s as though your transaction receives its own private snapshot of the database.

This provides a much more consistent view of the data, making it particularly useful for reporting systems and financial calculations.

However, Repeatable Read doesn’t necessarily prevent new rows from appearing that satisfy your query conditions.

Depending on the database implementation, phantom reads may still occur, although databases like PostgreSQL use Multi-Version Concurrency Control (MVCC) to eliminate many of these anomalies without locking every row.

This is one of the reasons database behavior differs slightly across vendors.

We’ll return to that shortly.

Repeatable Read Timeline

Transaction A                     Transaction B

BEGIN

Read Balance = 50,000

                               BEGIN

                               Deposit 100,000

                               COMMIT

Read Balance = 50,000 ✅

COMMIT

Although the database now contains KES 150,000, Transaction A continues seeing KES 50,000 because it is working from a consistent snapshot.

Serializable

Serializable is the strongest isolation level defined by the SQL standard.

The easiest way to understand it is to imagine that every transaction runs one after another instead of simultaneously.

Internally, the database may still execute many transactions concurrently, but it guarantees that the final result is identical to some serial execution order.

Returning to our concert ticket example, suppose only one seat remains.

Customer A begins purchasing the ticket.

Customer B attempts to purchase the same seat at exactly the same time.

Under Serializable isolation, the database ensures that only one transaction succeeds.

The other transaction must either wait, retry, or fail.

The database refuses to produce a result that couldn’t happen if the transactions had executed one after another.

This provides the strongest possible consistency guarantees.

It also comes at the highest performance cost.

Serializable transactions often require additional locking, conflict detection, or transaction retries.

For systems processing large volumes of concurrent requests, this can reduce throughput significantly.

Because of this, Serializable is typically reserved for situations where correctness is absolutely critical.

Financial ledgers, securities trading systems, and certain accounting operations are common examples.

Isolation Levels at a Glance

Isolation Level	Dirty Reads	Non-Repeatable Reads	Phantom Reads	Performance
Read Uncommitted	❌ Possible	❌ Possible	❌ Possible	⭐⭐⭐⭐⭐
Read Committed	✅ Prevented	❌ Possible	❌ Possible	⭐⭐⭐⭐
Repeatable Read	✅ Prevented	✅ Prevented	⚠ Depends on database	⭐⭐⭐
Serializable	✅ Prevented	✅ Prevented	✅ Prevented	⭐⭐

The table makes an important pattern clear.

As isolation increases, the number of concurrency anomalies decreases.

At the same time, the amount of coordination required by the database increases.

This is why there is no universally “best” isolation level.

The appropriate choice always depends on the requirements of your application.

Database Isolation Levels in Popular Databases

One detail that often surprises developers is that not every relational database implements isolation levels in exactly the same way.

The SQL standard defines the four isolation levels, but database vendors have some flexibility in how they achieve those guarantees.

For example, PostgreSQL relies heavily on Multi-Version Concurrency Control (MVCC). Instead of locking rows aggressively, PostgreSQL keeps multiple versions of a row and allows transactions to read a consistent snapshot of the data. This approach provides excellent concurrency while maintaining strong consistency.

MySQL’s InnoDB storage engine also supports MVCC but implements certain isolation behaviors differently. In particular, its default Repeatable Read isolation level prevents many phantom reads by using a combination of snapshot reads and gap locks.

SQL Server, on the other hand, traditionally relies more heavily on locking, although it also offers snapshot-based isolation levels that can be enabled when appropriate.

As a developer, you don’t need to memorize every implementation detail.

The important lesson is this:

Always understand how your specific database implements isolation before assuming its behavior.

The SQL standard provides the vocabulary, but your database documentation explains the exact behavior.

Choosing the Right Isolation Level

After learning about all four isolation levels, it’s natural to ask:

“Which one should I actually use?”

The honest answer is:

It depends on what you’re building.

Suppose you’re developing a dashboard that displays the number of users currently online.

If the number changes while someone refreshes the page, that’s perfectly acceptable.

There’s little value in sacrificing performance just to ensure every count remains identical throughout a transaction.

Read Committed is usually more than sufficient.

Now consider a payroll system.

Calculating employee salaries requires reading thousands of records while ensuring the figures don’t change halfway through the calculation.

If one employee’s salary is updated while payroll is being processed, the final report could contain inconsistent totals.

Repeatable Read becomes a much better fit because it provides a stable snapshot throughout the transaction.

Finally, imagine a securities trading platform or a banking ledger where even a single inconsistency could have significant financial consequences.

Here, correctness is more important than throughput.

Serializable isolation is often the safest choice, even if it means transactions occasionally wait or retry.

The goal isn’t to choose the strongest isolation level.

The goal is to choose the weakest isolation level that still guarantees the correctness your application requires.

Doing so allows the database to maximize concurrency without sacrificing business integrity.

Isolation Levels and Performance

One mistake developers sometimes make is assuming higher isolation is always better.

In reality, every additional guarantee comes at a cost.

Higher isolation levels typically require the database to:

Coordinate more transactions.
Acquire additional locks or maintain more snapshots.
Detect conflicts more aggressively.
Delay or retry conflicting transactions.

As concurrency increases, these costs become more noticeable.

A high-traffic e-commerce platform processing thousands of orders every minute cannot afford unnecessary waiting if a lower isolation level already satisfies its business rules.

Likewise, a financial institution cannot sacrifice correctness simply to process a few extra transactions per second.

Finding the right balance is part of designing reliable software.

Isolation Levels vs Transactions vs Race Conditions

At this point in the series, we’ve covered three concepts that are closely related but often confused.

Let’s put them side by side.

Transactions

Transactions answer the question:

What happens if my operation fails halfway through?

They ensure a group of related database operations either all succeed together or all fail together.

Without transactions, partial updates can leave your data inconsistent.

Race Conditions

Race conditions answer a different question:

What happens if two requests modify the same data at the same time?

These problems arise because multiple users or systems interact with shared data concurrently.

The outcome often depends entirely on timing.

Transactions alone don’t eliminate race conditions.

Additional mechanisms such as locking, optimistic concurrency, or stronger isolation levels are often required.

Isolation Levels

Isolation levels answer yet another question:

While another transaction is running, what am I allowed to see?

Should your transaction observe unfinished work?

Should it continue seeing the same data even after another transaction commits?

Should it behave as though it’s the only transaction running?

Isolation levels define these rules.

Together, these three concepts form the foundation of reliable database applications.

They complement one another rather than compete.

A payment system, for example, might use:

Idempotency to prevent duplicate payment requests.
Transactions to ensure payment records and account balances remain synchronized.
Read Committed or Serializable isolation to guarantee consistent reads.
Locking to prevent concurrent modifications of the same account.

No single technique solves every reliability problem.

Reliable systems combine several techniques, each addressing a different class of failure.

Practical Advice for Backend Developers

If you’re just beginning your backend engineering journey, don’t feel pressured to master every isolation level immediately.

Instead, focus on developing the habit of asking the right questions whenever you design a feature.

For example:

Could another user modify this data while I’m reading it?
If the same query runs twice, should it return the same result?
What happens if another transaction inserts new rows before mine finishes?
Is perfect consistency necessary, or is slightly stale data acceptable?
Would optimistic concurrency or explicit locking be a better solution?

Thinking through these questions early in the design process often prevents bugs that are incredibly difficult to diagnose later in production.

Many concurrency issues aren’t caused by writing incorrect code.

They’re caused by making incorrect assumptions about how multiple users interact with the same data simultaneously.

Final Thoughts

Database isolation levels are often presented as a collection of definitions that developers are expected to memorize.

In reality, they’re much simpler than they first appear.

They’re simply different answers to one question:

How much should one transaction be allowed to observe while another transaction is still working?

Lower isolation levels prioritize concurrency, allowing more users to interact with the database simultaneously.

Higher isolation levels prioritize consistency, ensuring every transaction sees a predictable view of the data.

Neither approach is universally correct.

The right choice depends entirely on the problem you’re solving.

As your applications grow, understanding isolation levels becomes increasingly important because concurrency is no longer the exception—it’s the norm.

Every online store, banking application, inventory system, booking platform, and loan management system eventually reaches a point where multiple transactions compete for the same data.

The developers who understand isolation levels don’t simply build applications that work.

They build applications that continue working correctly under real-world load.

What’s Next?

In this series we’ve explored:

Idempotency
Race Conditions
Database Transactions
Database Isolation Levels

We’ve learned how to protect our systems from duplicate requests, concurrent updates, partial failures, and inconsistent reads.

But one challenge still remains.

Everything we’ve discussed assumes our application is running on a single database.

What happens when your application is running on ten servers, each processing requests simultaneously?

A normal database lock isn’t always enough.

In the next article, we’ll explore Distributed Locks Explained: Coordinating Work Across Multiple Servers, where we’ll see how systems like Redis, ZooKeeper, and etcd help ensure that only one application instance performs a critical operation at a time.

Database Isolation Levels Explained: Why Two Transactions Can See Different Data

Billy Okeyo — Mon, 06 Jul 2026 00:00:00 +0000

“Transactions guarantee that your work completes correctly. Isolation levels determine what everyone else is allowed to see while that work is happening.”

In the previous article, we explored database transactions and learned how they ensure multiple database operations either succeed together or fail together. Transactions protect applications from partial execution, preventing situations where money is deducted from one account without being deposited into another or where inventory is reduced without successfully creating an order.

But transactions solve only part of the problem.

Modern applications rarely have just one user interacting with the database at a time. Thousands of customers may be placing orders, updating records, making payments, or querying reports simultaneously. Each of these actions runs inside its own transaction, and more often than not, several transactions are accessing the same data at exactly the same time.

This raises an important question:

What should one transaction be allowed to see while another transaction is still running?

Imagine opening your banking application to check your account balance.

At the exact same moment, your employer’s payroll system is depositing your monthly salary into the same account.

Should your transaction see the new balance immediately?

Should it continue seeing the old balance until the salary transaction finishes?

Should it wait until the payroll transaction completes before showing you anything at all?

Each answer is technically valid depending on how the database is configured.

Now imagine an online store where only one laptop remains in stock.

Customer A begins placing an order.

Before their transaction finishes, Customer B checks the product page.

Should Customer B still see one laptop available?

Should they see zero?

Should they wait until Customer A’s purchase either succeeds or fails?

Again, the answer depends on the database’s isolation level.

Isolation levels define the rules governing how concurrent transactions interact with one another. They determine whether one transaction can observe another transaction’s work before it has been completed, whether repeated reads always return the same result, and whether new rows appearing during a transaction should be visible immediately.

Although isolation levels are often introduced as an advanced database topic, they’re really about one simple idea:

How much of another transaction’s work should your transaction be allowed to see?

The answer has significant consequences for both correctness and performance.

In this article, we’ll explore why isolation levels exist, the concurrency problems they solve, the four SQL standard isolation levels, and how to choose the right one for your application.

Why Isolation Exists

To understand isolation, imagine you’re reading a book in a library.

Halfway through chapter three, someone walks over, quietly replaces several pages with new ones, and walks away.

You continue reading without realizing anything changed.

The beginning of the chapter describes one story.

The ending describes another.

Nothing makes sense.

Databases can experience a remarkably similar problem.

When multiple transactions execute simultaneously, each transaction may be reading data while another transaction is actively changing it.

Without rules governing these interactions, applications could make decisions based on incomplete information, outdated values, or data that is eventually discarded.

Isolation exists to prevent these situations.

Rather than allowing every transaction unrestricted access to every change happening in the database, the database controls what each transaction can observe and when it can observe it.

Think of it as putting walls between transactions.

Some walls are very thin.

Transactions can see almost everything happening around them.

Other walls are much thicker.

Transactions operate almost as though they’re the only users of the database.

The thicker the wall, the more isolated the transaction becomes.

The Trade-Off Between Consistency and Performance

At first glance, it might seem obvious that every database should simply use the highest possible isolation level.

After all, if stronger isolation produces more consistent data, why wouldn’t every system choose it?

The answer lies in performance.

Imagine a supermarket with only one checkout counter.

Every customer waits patiently in line.

Because only one cashier is serving customers, inventory updates happen one at a time.

Mistakes are rare.

Unfortunately, the queue becomes enormous.

Now imagine opening ten checkout counters.

Customers move much faster.

However, all ten cashiers are now updating the same inventory system simultaneously.

Keeping everything synchronized becomes much more difficult.

Databases face exactly the same challenge.

Higher isolation levels provide stronger guarantees about data consistency, but they often require additional locking, coordination, and waiting.

Lower isolation levels allow more transactions to execute concurrently, increasing throughput and reducing latency, but they also increase the likelihood that transactions observe changing data.

Isolation levels are therefore a balancing act between two competing goals:

Consistency, ensuring every transaction sees predictable and reliable data.
Concurrency, allowing as many users as possible to interact with the system simultaneously.

Different applications make different choices.

A banking application processing financial transfers typically prioritizes correctness over raw performance.

An analytics dashboard generating sales reports might tolerate slightly older data if it means thousands of users can run reports simultaneously without slowing the system.

Neither approach is universally correct.

The appropriate isolation level depends entirely on your business requirements.

Concurrency Anomalies: The Problems Isolation Levels Exist to Solve

Isolation levels were not invented simply to make databases more complicated.

They exist because concurrent transactions can produce behaviors that most developers would consider surprising—or even dangerous.

These unexpected behaviors are collectively known as concurrency anomalies.

Every isolation level is essentially a trade-off between preventing these anomalies and maintaining good performance.

Before discussing the isolation levels themselves, it’s important to understand the problems they are designed to solve.

The four anomalies you’ll encounter most often are:

Dirty Reads
Non-Repeatable Reads
Phantom Reads
Lost Updates

Each represents a different way concurrent transactions can interfere with one another.

Let’s begin with the simplest.

Dirty Reads

Imagine Alice has KES 50,000 in her account.

She initiates a transfer of KES 20,000 to another account.

The banking system begins processing the transaction.

The first step deducts the money from Alice’s balance.

Before the transaction finishes, another process—perhaps an ATM balance inquiry or an online banking session—checks Alice’s account.

At that moment, it sees a balance of KES 30,000.

Everything seems perfectly normal.

Then something unexpected happens.

The transfer fails because the destination account no longer exists.

The database rolls back the transaction.

Alice’s balance immediately returns to KES 50,000.

The second transaction has now made a decision based on information that never officially existed.

It observed data that was eventually discarded.

This is known as a Dirty Read.

A dirty read occurs when one transaction reads data written by another transaction before that transaction has been committed.

The easiest way to understand it is to imagine reading someone’s unfinished draft before they’ve decided whether to keep or delete it.

The version you read may never become the final version.

Making business decisions based on that draft could lead to incorrect outcomes.

Fortunately, most modern relational databases prevent dirty reads by default because they are rarely desirable in business applications.

The SQL standard still defines them because they help explain the spectrum of isolation levels.

Timeline of a Dirty Read

Transaction A                     Transaction B

BEGIN

Balance = 50,000

↓

Update Balance = 30,000

                               Read Balance = 30,000 ❌

↓

Transfer Fails

↓

ROLLBACK

Balance returns to 50,000

Transaction B has observed a value that disappeared moments later.

From the perspective of the database, that balance never officially existed.

Yet another transaction already acted as though it did.

This is precisely the type of inconsistency isolation levels are designed to prevent.

Non-Repeatable Reads

Suppose you’re building an online banking application.

A customer opens the app and views their account balance. At that moment, the database reports a balance of KES 50,000.

The customer decides to transfer KES 40,000 to another account, but before confirming the transfer, the application performs one final balance check to ensure sufficient funds are still available.

This seems like a perfectly reasonable workflow.

However, between the first balance check and the second, another transaction deposits KES 100,000 into the same account.

When the application performs the second query, the balance is no longer KES 50,000.

It’s now KES 150,000.

Nothing is technically wrong.

The second transaction committed successfully.

The balance genuinely changed.

The surprising part is that the same transaction read the same row twice and received two different answers.

This phenomenon is known as a Non-Repeatable Read.

Unlike a dirty read, the second transaction isn’t reading uncommitted data. Every value it sees has been permanently committed to the database.

The inconsistency comes from the fact that another transaction modified the row while the first transaction was still running.

Imagine reading yesterday’s newspaper while someone keeps replacing pages with today’s edition.

The information isn’t incorrect.

It’s simply inconsistent because the document changed while you were reading it.

For many applications, this isn’t a problem.

If you’re refreshing a weather dashboard or checking the number of users currently online, it’s perfectly acceptable for values to change between two queries.

However, systems that rely on a stable snapshot of data—such as financial reporting, payroll processing, or end-of-day reconciliation—often require the same query to return the same result throughout the entire transaction.

Timeline of a Non-Repeatable Read

Transaction A                     Transaction B

BEGIN

Read Balance = 50,000

                               BEGIN

                               Deposit 100,000

                               COMMIT

Read Balance = 150,000 ❌

COMMIT

Transaction A never modified the balance itself.

It simply asked the same question twice and received two different answers because another committed transaction changed the underlying data in the meantime.

Real-World Example: Updating a Customer Profile

Consider an insurance application where a customer service representative opens a customer’s profile.

The representative spends several minutes reviewing the information before approving a policy update.

Meanwhile, another employee updates the customer’s phone number and address.

When the representative finally clicks Save, the application may now be working with information that is different from what was originally displayed.

Depending on how the application handles these changes, it could accidentally overwrite newer data or make decisions using outdated information.

This isn’t a database bug.

It’s simply the natural consequence of multiple users interacting with the same record at the same time.

Applications that require users to work with a consistent view of the data often use higher isolation levels or optimistic concurrency controls to detect these situations before committing changes.

Phantom Reads

Now let’s consider a different scenario.

Instead of reading a single row twice, imagine you’re querying an entire collection of rows.

Suppose you’re generating a report showing all loan applications submitted today.

Your first query returns:

Loan Applications Submitted Today

-------------------------------

Loan #101

Loan #102

Loan #103

Total: 3

While your report is still running, another loan application is submitted and committed to the database.

A few moments later, your transaction performs the exact same query again.

This time the results look different.

Loan Applications Submitted Today

-------------------------------

Loan #101

Loan #102

Loan #103

Loan #104

Total: 4

Notice what changed.

None of the existing rows were modified.

Instead, an entirely new row appeared.

This is called a Phantom Read.

A phantom read occurs when the same query returns a different set of rows because another transaction inserted, updated, or deleted records that match the query’s search criteria.

Think of it like counting the number of people in a room.

You count 20 people.

While you’re writing the number down, someone walks into the room.

You count again.

Now there are 21 people.

Nothing about the original twenty people changed.

The difference is that a new “phantom” appeared between your two observations.

Timeline of a Phantom Read

Transaction A                     Transaction B

BEGIN

SELECT *

WHERE loan_date = TODAY

Returns 3 rows

                               BEGIN

                               INSERT Loan #104

                               COMMIT

SELECT *

WHERE loan_date = TODAY

Returns 4 rows ❌

COMMIT

Unlike a non-repeatable read, where an existing row changes, phantom reads involve the appearance or disappearance of entire rows.

Why Phantom Reads Matter

Imagine you’re calculating today’s total revenue for financial reporting.

Your reporting transaction begins at 5:00 PM and starts aggregating sales.

While it’s still processing, new sales continue being recorded.

Different parts of the report may now be working with different datasets.

The total revenue calculated on page one might not match the detailed transaction list generated on page five because new rows appeared while the report was still executing.

In reporting systems, this can produce confusing and inconsistent results.

Higher isolation levels solve this problem by ensuring the transaction sees a consistent snapshot of the data throughout its lifetime, even if other transactions continue inserting new rows.

Lost Updates

The final concurrency anomaly is perhaps the most dangerous because it silently discards valid work.

Imagine two warehouse employees looking at the same inventory record.

The system currently shows:

Laptop Stock = 10

Employee A sells one laptop.

Employee B also sells one laptop at almost exactly the same time.

Both employees read the current stock before making their update.

Each calculates the new quantity as:

10 - 1 = 9

Employee A saves.

The inventory becomes:

A fraction of a second later, Employee B saves.

The inventory is still:

One of the updates has effectively disappeared.

The correct inventory should now be 8, but because both transactions started from the same original value, one update overwrote the other.

This is known as a Lost Update.

Unlike the previous anomalies, nothing appears obviously wrong.

No errors occur.

No constraints are violated.

The database happily accepts both updates.

The problem is that one user’s work has unintentionally replaced another’s.

Lost updates are one of the primary reasons databases provide row locking, optimistic concurrency control, and stronger isolation levels.

Without these protections, applications that receive many simultaneous updates—such as inventory systems, banking platforms, or booking applications—can slowly drift away from reality without anyone noticing.

Now that we understand the problems, the next question is obvious: How do databases prevent them? That’s exactly what we’ll cover in Part 2.”

DEV Community: Billy Okeyo

Client-Side Rendering vs Server-Side Rendering Explained: Where Should Your UI Be Built?

What Is Client-Side Rendering?

Why Client-Side Rendering Became Popular

The Client-Side Rendering Experience

The Empty Page Problem

What Is Server-Side Rendering?

A Simple Server-Side Example

CSR vs SSR: The Fundamental Difference

But Server-Rendered HTML Isn’t Necessarily Interactive

Initial Load Performance

Time to First Byte vs Useful Content

SEO and Crawlers

CSR Can Be Excellent for Application-Like Interfaces

SSR Has a Server Cost

Static Site Generation Enters the Picture

CSR vs SSR vs SSG

Client-Side Rendering

Server-Side Rendering

Static Site Generation

Modern Applications Are Hybrid

Next.js and Hybrid Rendering

Server Components Add Another Dimension

The JavaScript Cost Still Matters

Data Fetching Changes Too

Caching Changes the Equation

Personalized Pages Are Different

Failure Modes Are Different

What About Navigation After the First Page?

When Should You Choose CSR?

When Should You Choose SSR?

When Should You Choose SSG?

The Wrong Question: “Which Is Faster?”

Application A

Application B

A Better Decision Framework

Does the content need SEO?

Is the page highly personalized?

Does the content change frequently?

Is the application highly interactive?

Is the page mostly content?

Can the output be cached?

Does the user stay in the application for a long time?

Common Mistake: SSR Everything

Common Mistake: CSR Everything

Common Mistake: Choosing Based on Framework Hype

A Practical Architecture

CSR and SSR Are Not Opponents

Bringing It All Together

Final Thoughts

What’s Next?

The JavaScript Event Loop Explained: Why Your UI Freezes

JavaScript Is Single-Threaded

The Call Stack

So How Does Asynchronous JavaScript Work?

Why setTimeout(..., 0) Doesn’t Mean Immediately

Tasks and the Task Queue

Enter Microtasks

What Creates Microtasks?

Microtask Starvation

Why Your UI Freezes

The Loading Spinner That Never Spins

Rendering and the Event Loop

Breaking Expensive Work Into Smaller Pieces

What About async and await?

setTimeout Isn’t a Background Thread Either

Web Workers: Actually Moving Work Off the Main Thread

requestAnimationFrame

Tasks vs Microtasks vs Animation Frames

A Practical Example: Processing a Large Dataset

Long Tasks and the 16.7ms Frame Budget

The Event Loop Explains Delayed Clicks Too

Frameworks Still Depend on the Event Loop

Common Event Loop Mistakes

How to Keep the UI Responsive

Putting the Event Loop Together

Bringing It All Together

Final Thoughts

What’s Next?

Reflow and Repaint Explained: Why Some UI Updates Are Expensive

Why `setTimeout(..., 0)` Doesn’t Mean Immediately

What About `async` and `await`?

`setTimeout` Isn’t a Background Thread Either

`requestAnimationFrame`

`will-change`: Useful but Easy to Abuse