DEV Community: Billy Okeyo

Re-Renders Explained: What Actually Happens When Frontend State Changes

Billy Okeyo — Fri, 11 Sep 2026 00:00:00 +0000

One of the most common pieces of advice in frontend development is:

Avoid unnecessary re-renders.

You hear it when working with React, when discussing component performance, and when someone suggests memo, useMemo, or useCallback; eventually, it can start sounding as though re-rendering is inherently bad, but it isn’t.

Re-rendering is how modern UI frameworks keep the screen synchronized with application state.

Consider a simple counter:

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

The browser initially displays:

Count: 0

Then the user clicks the button.

Count: 0
    │
    │ click
    ▼
setCount(1)

The component re-renders.

Eventually, the browser displays:

Count: 1

That process sounds simple, but there are several steps hidden in between.

React doesn’t immediately replace the entire DOM.

The browser doesn’t repaint the entire page just because a state variable changed.

Instead, the framework performs work to determine what the UI should now look like, compares that result with what existed before, and updates only the parts of the real DOM that actually changed.

A simplified mental model looks like this:

State Change
    │
    ▼
Component Re-renders
    │
    ▼
New UI Description
    │
    ▼
Compare With Previous Result
    │
    ▼
Determine Actual Changes
    │
    ▼
Update DOM
    │
    ▼
Browser Rendering Pipeline

Understanding this process is important because it helps separate two ideas developers often confuse: React rendering and browser rendering, which are not the same thing.

React Rendering Is Not Browser Rendering

In the first article in this series, we explored the browser rendering pipeline:

DOM
 │
 ▼
Style
 │
 ▼
Layout
 │
 ▼
Paint
 │
 ▼
Composite
 │
 ▼
Pixels

That process belongs to the browser.

React’s rendering happens before that.

React decides what the DOM should look like.

The browser decides how that DOM becomes pixels.

Conceptually:

Application State
      │
      ▼
     React
      │
      ▼
DOM Changes
      │
      ▼
   Browser
      │
      ▼
Layout / Paint / Composite

This distinction matters.

A React component can re-render without causing any DOM update at all.

And if the DOM doesn’t change, the browser may have very little visual work to do.

What Happens When State Changes?

Let’s use a slightly larger example.

function Profile() {
  const [name, setName] = useState("Billy");

  return (
    <section>
      <h1>Hello, {name}</h1>

      <button onClick={() => setName("William")}>
        Change Name
      </button>
    </section>
  );
}

Initially, React produces a UI description conceptually similar to:

section
├── h1
│   └── "Hello, Billy"
└── button
    └── "Change Name"

After:

setName("William");

React renders the component again.

Now the result looks like:

section
├── h1
│   └── "Hello, William"
└── button
    └── "Change Name"

Most of the structure is identical.

Only one text value changed.

So React does not need to rebuild the entire DOM.

It only needs to update:

"Hello, Billy"
       ↓
"Hello, William"

The process can be understood as three broad stages:

Render
   │
   ▼
Reconciliation
   │
   ▼
Commit

Let’s look at each one.

The Render Phase

When a component re-renders, React executes the component function again.

That point is worth emphasizing.

Consider:

function Counter() {
  console.log("Counter rendered");

  const [count, setCount] = useState(0);

  return <p>{count}</p>;
}

Whenever React renders Counter, the function executes.

That means:

console.log("Counter rendered");

runs again.

So rendering does not mean React simply reuses the previous function result.

The component runs again to determine what the UI should look like for the current state and props.

Conceptually:

State = 0

Counter()
   │
   ▼
<p>0</p>

Then:

State = 1

Counter()
   │
   ▼
<p>1</p>

React now has a new description of the UI.

But no DOM changes necessarily happened yet.

That distinction becomes very important.

Reconciliation

Once React has the new result, it compares it with the previous one.

This process is known as reconciliation.

Suppose before:

<div>
  <h1>Products</h1>
  <p>3 items</p>
</div>

and after:

<div>
  <h1>Products</h1>
  <p>4 items</p>
</div>

The structure did not change.

The div still exists.

The h1 is the same.

Only the paragraph text changed.

React can therefore conclude:

Keep div
Keep h1
Keep p
Update text

instead of:

Delete everything
Recreate everything

This is the heart of reconciliation.

React is determining the minimum DOM work needed to make the actual interface match the new component output.

The Commit Phase

Once React knows what needs to change, it performs those mutations during the commit phase.

This is where the real DOM is updated.

So the flow becomes:

State Change
    │
    ▼
Render Phase
Component functions run
    │
    ▼
Reconciliation
Compare old and new
    │
    ▼
Commit Phase
Update actual DOM

Only after actual DOM changes occur does the browser potentially need to perform its own rendering work.

React Commit
     │
     ▼
DOM Changed
     │
     ▼
Browser
     │
     ├── Style?
     ├── Layout?
     ├── Paint?
     └── Composite?

This connects directly to everything we learned about reflow and repaint.

Re-Rendering Does Not Mean DOM Mutation

This is one of the biggest misconceptions in React performance discussions.

Suppose:

function Greeting({ name }) {
  console.log("render");

  return <h1>Hello {name}</h1>;
}

React may execute this component again.

But if:

name = "Billy"

both before and after the render, the resulting UI may be identical.

React can determine:

Previous: <h1>Hello Billy</h1>

New:      <h1>Hello Billy</h1>

No meaningful DOM change is required.

So:

Component Render
      ≠
DOM Update

And:

DOM Update
      ≠
Full Browser Repaint

These are separate stages.

That is why the statement:

“This component rendered again!”

doesn’t automatically mean:

“We have a serious performance problem.”

The cost depends on what happens during that render and what actual work follows.

Why Child Components Re-Render

This is another area that confuses many developers.

Consider:

function App() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>

      <Header />
    </>
  );
}

Header doesn’t use count.

Yet when App re-renders, Header may also render again.

Why?

Because Header is part of the component tree produced by App.

Conceptually:

App re-renders
    │
    ├── Button
    │
    └── Header

React walks through that subtree to determine what the updated UI should look like.

Again, this doesn’t necessarily mean the DOM represented by Header changes.

The component can execute again while producing exactly the same result.

Parent Re-Render Does Not Mean Everything Changed

Suppose:

function Header() {
  return (
    <header>
      <h1>My Store</h1>
    </header>
  );
}

Every time the parent renders, this may execute again.

But React compares:

Previous Header

<header>
  <h1>My Store</h1>
</header>

with:

New Header

<header>
  <h1>My Store</h1>
</header>

Nothing changed.

So no DOM mutation is required.

This is why React can tolerate far more component renders than developers often assume.

The framework is designed around the idea that rendering should generally be cheap.

Problems appear when rendering itself becomes expensive.

When Re-Renders Actually Become Expensive

Imagine a component does this:

function Analytics({ transactions }) {
  const report = generateComplexReport(transactions);

  return <ReportView report={report} />;
}

If generateComplexReport() processes hundreds of thousands of records, every render can become expensive.

Now suppose a parent re-renders frequently.

Parent changes
     │
     ▼
Analytics renders
     │
     ▼
Expensive calculation

Even if the resulting DOM doesn’t change, the expensive JavaScript already ran.

This is where unnecessary rendering becomes a real performance problem.

The issue isn’t:

DOM updated too much

It might instead be:

JavaScript executed too much

That connects directly to the Event Loop article.

Heavy component rendering occupies the main thread just like any other JavaScript.

A Simple Example of Expensive Rendering

Consider:

function ProductList({ products, search }) {
  const results = products
    .filter(product =>
      product.name
        .toLowerCase()
        .includes(search.toLowerCase())
    )
    .sort((a, b) => a.price - b.price);

  return (
    <ul>
      {results.map(product => (
        <li key={product.id}>
          {product.name}
        </li>
      ))}
    </ul>
  );
}

For:

50 products

this probably doesn’t matter.

For:

500,000 products

it might.

Now imagine an unrelated state change causes the component to render repeatedly.

Theme toggled
     │
     ▼
Parent re-render
     │
     ▼
ProductList executes
     │
     ▼
Filter 500,000 products
     │
     ▼
Sort 500,000 products

Even if the product list itself didn’t actually change, substantial work occurred.

This is where memoization can help.

What `useMemo` Actually Does

Consider:

const filteredProducts = useMemo(() => {
  return products.filter(product =>
    product.name.includes(search)
  );
}, [products, search]);

The goal of useMemo is not:

Make React faster.

Its purpose is more specific.

It says:

Recalculate this value only when these dependencies change.

Conceptually:

Render
  │
  ▼
Did products or search change?
      │
   ┌──┴───┐
   │      │
  Yes     No
   │      │
   ▼      ▼
Calculate  Reuse

If some unrelated state changes:

sidebarOpen

the component may still re-render.

But the expensive product filtering can be skipped.

This distinction is important.

useMemo doesn’t necessarily prevent rendering.

It prevents recalculating a memoized result when dependencies haven’t changed.

Do Not Memoize Everything

After learning about useMemo, it’s tempting to do this:

const name = useMemo(() => {
  return `${firstName} ${lastName}`;
}, [firstName, lastName]);

But calculating:

`${firstName} ${lastName}`

is extremely cheap.

Now we’ve added:

Memoization logic
Dependency tracking
Additional code
Mental overhead

to avoid a trivial string concatenation.

Optimization itself has a cost.

A useful rule is:

Memoize expensive computations or values whose identity meaningfully matters, not every expression in your component.

Measure before making everything more complicated.

`React.memo`

Now suppose the expensive work happens inside a child component.

function Dashboard() {
  const [sidebarOpen, setSidebarOpen] = useState(false);

  return (
    <>
      <Sidebar open={sidebarOpen} />
      <ExpensiveChart />
    </>
  );
}

When sidebarOpen changes:

Dashboard re-renders
      │
      ├── Sidebar
      └── ExpensiveChart

But ExpensiveChart receives no changing props.

We may wrap it:

const ExpensiveChart = React.memo(function ExpensiveChart() {
  return <Chart />;
});

Now React can compare its props and potentially skip rendering the component when those props haven’t changed.

Conceptually:

Parent re-renders
      │
      ▼
Check child props
      │
   ┌──┴───┐
   │      │
Changed  Same
   │      │
   ▼      ▼
Render   Skip

Again, the point isn’t that every child should use React.memo.

It is useful when:

The component renders frequently
Rendering is meaningfully expensive
Its props often remain unchanged

Otherwise, the additional complexity may provide little benefit.

Why `React.memo` Sometimes Doesn’t Work

Consider:

const ProductCard = React.memo(function ProductCard({
  product,
  onSelect
}) {
  return (
    <button onClick={() => onSelect(product.id)}>
      {product.name}
    </button>
  );
});

The parent does:

<ProductCard
  product={product}
  onSelect={(id) => setSelectedId(id)}
/>

Every parent render creates a new function:

(id) => setSelectedId(id)

Even though the function does the same thing, its identity is new.

Conceptually:

Previous render:

onSelect = Function A

New render:

onSelect = Function B

So from a shallow prop-comparison perspective:

Function A !== Function B

and the memoized child may render again.

This is where useCallback enters the picture.

What `useCallback` Actually Does

You might write:

const handleSelect = useCallback((id) => {
  setSelectedId(id);
}, []);

Then:

<ProductCard
  product={product}
  onSelect={handleSelect}
/>

Now the function reference can remain stable across renders unless its dependencies change.

Conceptually:

Render 1
handleSelect = Function A

Render 2
handleSelect = Function A

Render 3
handleSelect = Function A

This can help when function identity matters, especially when passing callbacks into memoized child components.

But again:

useCallback does not magically make a function faster.

It memoizes the function reference.

If nothing depends on that identity, it may provide no practical benefit.

`useMemo` vs `useCallback`

The difference is simple.

useMemo memoizes a value.

const total = useMemo(() => {
  return calculateTotal(items);
}, [items]);

useCallback memoizes a function reference.

const handleSave = useCallback(() => {
  save(items);
}, [items]);

Conceptually:

useMemo
   │
   ▼
Remember result


useCallback
   │
   ▼
Remember function

Both are performance tools.

Neither should automatically appear everywhere.

Object Identity Causes Similar Problems

Suppose:

<Chart
  options={{
    showLegend: true,
    responsive: true
  }}
/>

Every render creates a new object.

Render 1 → Object A

Render 2 → Object B

Even though:

Object A contents
      =
Object B contents

their references differ.

If Chart is memoized and relies on shallow prop comparison, it may still render again.

One solution can be:

const options = useMemo(() => ({
  showLegend: true,
  responsive: true
}), []);

<Chart options={options} />

Now the object identity remains stable.

But the same warning applies:

Only optimize where the identity actually causes meaningful work.

Keys and Reconciliation

Keys are another important part of how React reasons about changes.

Consider:

{products.map(product => (
  <ProductCard
    key={product.id}
    product={product}
  />
))}

The key helps React identify which item corresponds to which previous item.

Suppose:

Before

A
B
C

then:

After

A
X
B
C

With stable keys, React can understand:

A → same
X → new
B → same
C → same

Without useful identity, React has a harder time reasoning about which items moved, appeared, or disappeared.

This matters not only for performance but also for preserving component state correctly.

Why Array Index Keys Can Be Problematic

Consider:

items.map((item, index) => (
  <Row key={index} item={item} />
));

Suppose:

0 → Alice
1 → Billy
2 → John

Then Alice is removed.

Now:

0 → Billy
1 → John

React sees:

key 0 still exists
key 1 still exists

even though the underlying items associated with those positions changed.

This can cause surprising state behaviour in interactive lists.

Stable business identifiers are usually better:

<Row
  key={user.id}
  item={user}
/>

Keys are fundamentally about identity.

They tell React:

This element represents the same conceptual thing as before.

State Position Matters

React associates state with a component’s position and identity in the rendered tree.

Imagine:

{loggedIn ? (
  <Dashboard />
) : (
  <Login />
)}

When the condition changes, one component leaves and another enters.

Its state lifecycle changes accordingly.

Similarly, changing a component’s key can cause React to treat it as a new component.

For example:

<Profile key={userId} userId={userId} />

Changing:

userId = 1

to:

userId = 2

can intentionally reset Profile state because React treats the new key as a different identity.

This can be useful for cases such as resetting forms when switching records.

Render Phase vs Effects

Now consider:

function Profile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser(userId).then(setUser);
  }, [userId]);

  return <ProfileView user={user} />;
}

The effect doesn’t run in the middle of calculating the component’s JSX.

Rendering determines what the UI should look like.

Effects are for synchronizing with things outside the pure render calculation, such as:

Network
Browser APIs
Subscriptions
Timers
Third-party libraries

This distinction helps explain why render functions should ideally remain pure.

Given the same state and props:

same input
   │
   ▼
same UI description

That makes React’s rendering model much easier to reason about.

Why Side Effects During Render Are Dangerous

Imagine:

function BadComponent() {
  fetch("/api/analytics");

  return <div>Hello</div>;
}

Every render triggers a network request.

If the component renders three times:

Render 1 → request

Render 2 → request

Render 3 → request

Now application behavior depends on how often React happens to render.

That is fragile.

Rendering should describe UI, not perform unrelated side effects.

Those operations belong in appropriate event handlers, effects, or data-fetching mechanisms.

Strict Mode Can Make This More Visible

During development, React Strict Mode may intentionally invoke certain logic more than once to help expose impure rendering and incorrect effect handling.

Developers sometimes see:

Why is this component rendering twice?

and assume React is broken.

But development behavior may deliberately stress-test assumptions.

That is another reason not to attach important side effects directly to render execution.

A component should remain safe to evaluate when React needs to understand what the UI should look like.

Re-Renders and Context

Suppose:

<AppContext.Provider
  value={{
    user,
    theme,
    cart,
    notifications
  }}
>
  <App />
</AppContext.Provider>

Many components consume this context.

Then:

notifications changes

The provider’s value changes.

Consumers may need to render again, including ones primarily interested in other parts of that context.

This is why very large contexts can sometimes become performance hotspots.

A better architecture might separate concerns:

UserContext

ThemeContext

CartContext

NotificationContext

or use a store with selector-based subscriptions.

Again, the principle from the previous state-management articles applies:

State distribution affects how much of your component tree responds when state changes.

Global State and Selectors

Imagine a store containing:

user
cart
theme
notifications
sidebar
products

A component needs only:

cart.length

A selector lets it subscribe to that specific information.

Conceptually:

Global Store
    │
    ├── Component A → user
    │
    ├── Component B → cart count
    │
    └── Component C → theme

Now:

user changes

doesn’t necessarily require the cart-count component to render.

This is one reason state architecture and rendering performance are deeply connected.

The question isn’t only:

Where do we store state?

It is also:

Which components are notified when that state changes?

Server State Can Trigger Re-Renders Too

From the previous article, we know server-state libraries maintain cached data.

Suppose:

const { data: products } = useQuery({
  queryKey: ["products"],
  queryFn: fetchProducts
});

The cache receives updated server data.

Old Products
      │
      ▼
Query Refetch
      │
      ▼
New Products
      │
      ▼
Subscribed Components Re-render

That is expected.

The important thing is that components interested in unrelated queries don’t need to respond.

Well-designed subscriptions help contain updates to the parts of the interface that actually care about them.

Rendering Large Lists

One place re-render costs become very visible is large collections.

Suppose:

{transactions.map(transaction => (
  <TransactionRow
    key={transaction.id}
    transaction={transaction}
  />
))}

For:

20 transactions

probably fine.

For:

100,000 transactions

you have a different problem.

Even if React efficiently reconciles the list, rendering and maintaining tens of thousands of DOM elements is expensive.

This is where virtualization becomes useful.

Instead of rendering every row:

Rows 1 → 100,000

render only the ones currently visible:

Rows 420 → 450

Conceptually:

Dataset

100,000 rows
     │
     ▼
Virtualizer
     │
     ▼
Visible viewport
     │
     ▼
~30 DOM rows

This reduces both framework rendering work and browser DOM/rendering work.

Libraries such as TanStack Virtual and react-window use this approach.

Component Boundaries Matter

Imagine one enormous component:

function Dashboard() {
  // 2,000 lines of state, calculations and JSX
}

Any state change causes that component’s render logic to execute again.

Breaking the interface into meaningful components can create clearer boundaries:

Dashboard
│
├── Header
├── BalanceCard
├── Transactions
├── SpendingChart
└── Goals

This does not automatically guarantee fewer renders.

But it creates opportunities for:

Independent state ownership
Memoization
Selective subscriptions
Smaller render workloads
Clearer architecture

Good component design is therefore partly about defining sensible rendering boundaries.

Should You Fear Re-Renders?

No.

This is probably the most important practical lesson in the article.

A component doing this:

function Name({ name }) {
  return <p>{name}</p>;
}

can execute extremely quickly.

Spending hours preventing that component from rendering again may make your code harder to maintain without producing any measurable user benefit.

Meanwhile, a single component containing:

Expensive calculations
Large lists
Complex charts
Heavy parsing

can create real problems.

So instead of:

How do I stop all re-renders?

ask:

Which renders are actually expensive?

That is a much healthier performance mindset.

The Wrong Way to Optimize

A codebase can quickly become:

const Component = memo(({ value }) => {
  const result = useMemo(() => calculate(value), [value]);

  const onClick = useCallback(() => {
    ...
  }, []);

  ...
});

everywhere.

Memoization becomes the default rather than a targeted optimization.

Now every developer has to reason about:

Dependencies
Stable references
Memoization boundaries
Stale closures
Prop identity

even when the underlying render takes microseconds.

You’ve optimized the framework workload while increasing human workload.

That’s not always a good trade.

Measure Before Optimizing

The browser and React both provide tools for identifying performance problems.

React DevTools includes profiling capabilities that can help answer questions such as:

Which component rendered?

How long did it take?

Why did it render?

Which parts of the tree were expensive?

Browser performance tools can then show what happened afterward:

JavaScript
     │
     ▼
DOM Commit
     │
     ▼
Layout
     │
     ▼
Paint

Combining the two gives you a much clearer picture.

Perhaps React rendering is expensive.

Perhaps React is fast and browser layout is the real problem.

Perhaps neither is the bottleneck and you’re waiting on a network request.

Optimization should follow evidence.

A Practical Example

Suppose a dashboard has:

function Dashboard() {
  const [sidebarOpen, setSidebarOpen] = useState(false);

  return (
    <>
      <Sidebar
        open={sidebarOpen}
        onClose={() => setSidebarOpen(false)}
      />

      <TransactionsTable />

      <LargeAnalyticsChart />
    </>
  );
}

Toggling the sidebar causes the dashboard to re-render.

If both TransactionsTable and LargeAnalyticsChart are cheap, stop there.

There may be nothing worth optimizing.

But suppose profiling reveals:

LargeAnalyticsChart render

180ms

every time the sidebar changes.

Now there is a measurable problem.

If the chart’s props remain unchanged, memoization may be appropriate:

const LargeAnalyticsChart = memo(
  function LargeAnalyticsChart({ data }) {
    return <Chart data={data} />;
  }
);

Perhaps chart data also requires an expensive transformation:

const chartData = useMemo(() => {
  return calculateAnalytics(transactions);
}, [transactions]);

Now the optimization has a reason.

Before

Sidebar toggle
     │
     ▼
Expensive analytics calculation
     │
     ▼
Chart render


After

Sidebar toggle
     │
     ▼
Cached analytics
     │
     ▼
Chart skipped / cheaper work

That’s much better than adding memoization everywhere “just in case.”

Rendering vs Committing

Another useful distinction is that React may perform rendering work that never reaches the DOM.

In modern React, rendering work can sometimes be interrupted, restarted, or discarded before it is committed.

That means:

Render work
    │
    ▼
Does React commit it?
    │
 ┌──┴───┐
 │      │
Yes     No
 │      │
 ▼      ▼
DOM    Discard

This is one reason render logic must remain pure.

React may evaluate a component without guaranteeing that the result becomes visible.

Side effects during rendering would therefore become unpredictable.

The commit phase is the point at which actual DOM changes are applied.

Re-Renders and the Event Loop

Everything we’ve discussed ultimately happens as JavaScript work on the main thread.

Suppose several expensive components render after one state update.

State Update
     │
     ▼
Component A     30ms
     │
Component B     40ms
     │
Component C     50ms
     │
     ▼
Total JS        120ms

The Event Loop article taught us what that means.

While this work runs:

User click       waiting
Animation        waiting
Rendering        waiting
Other JS         waiting

The issue isn’t merely that React “rendered too many times.”

The user-visible problem is that the main thread was occupied for too long.

That is why frontend performance concepts keep connecting back to one another.

Re-Renders and the Browser Rendering Pipeline

Now suppose React finishes reconciliation and commits:

width: 300px
      │
      ▼
width: 600px

React’s work is finished.

But the browser may now need:

Style
  │
  ▼
Layout
  │
  ▼
Paint
  │
  ▼
Composite

Alternatively, React might commit:

opacity: 0
     │
     ▼
opacity: 1

which may be handled much more cheaply.

So frontend performance has at least two separate dimensions:

Framework Work

Component rendering
Reconciliation
DOM updates

        +

Browser Work

Style
Layout
Paint
Composite

Optimizing only one side can leave the actual bottleneck untouched.

A Better Mental Model

When state changes, don’t imagine:

State changes
     │
     ▼
Entire page rebuilt

Think:

State changes
     │
     ▼
Affected component tree evaluated
     │
     ▼
New UI description
     │
     ▼
React reconciles
     │
     ▼
Actual differences identified
     │
     ▼
Necessary DOM mutations committed
     │
     ▼
Browser processes those changes

Every arrow represents a potential cost.

But none should automatically be assumed to be expensive.

Practical Rules for Re-Render Performance

A few principles go a long way: keep state as close as practical to the components that actually need it, avoid placing rapidly changing local state unnecessarily high in the tree, and avoid repeating expensive calculations on every render when memoization or restructuring can prevent that work.

Use stable keys for lists, apply memoization when profiling shows meaningful savings, design Context boundaries and global store subscriptions intentionally, virtualize genuinely large lists, and avoid side effects during render.

Above all, do not optimize purely based on how many renders a console statement reports.

A render is only a problem when the work involved is actually expensive enough to matter.

Bringing It All Together

A state update begins inside your application:

State
  │
  ▼
Re-render

That re-render produces a new description of the UI.

Component Function
       │
       ▼
New Element Tree

React compares it with what came before.

Previous Tree
      │
      ├────► Reconciliation
      │
New Tree

Only necessary changes are committed.

Difference
    │
    ▼
DOM Mutation

Then the browser takes over.

DOM
 │
 ▼
Style
 │
 ▼
Layout
 │
 ▼
Paint
 │
 ▼
Composite
 │
 ▼
Pixels

That gives us the full chain:

State Change
      │
      ▼
Component Render
      │
      ▼
Reconciliation
      │
      ▼
Commit
      │
      ▼
DOM Change
      │
      ▼
Browser Rendering
      │
      ▼
Updated Pixels

Once you understand those boundaries, performance discussions become much clearer.

You can ask:

Is the component render expensive?

Is reconciliation expensive?

Are we committing too many DOM changes?

Is layout the real problem?

Is painting expensive?

Is the main thread blocked?

Those are much better questions than simply asking:

Why is React re-rendering?

Final Thoughts

Re-renders have a reputation they do not entirely deserve: they are not bugs, they are not automatically performance problems, and preventing every possible render is not the goal of frontend engineering.

Rendering is how declarative UI frameworks work.

You describe:

What the UI should look like
for the current state.

Then the framework figures out how to get there.

The real performance question is not whether components render, but whether the amount of work happening during those renders prevents the application from delivering a smooth experience.

Sometimes the answer is yes: a large calculation runs repeatedly, a huge list is rendered unnecessarily, or a global state update wakes up hundreds of components, and those cases deserve optimization.

But often, rendering is already cheap, and in those cases adding layers of memoization can make the code harder to understand without making the application noticeably faster.

So the next time you see a component render again, don’t immediately ask:

“How do I stop this?”

Ask:

“What work is this render actually doing, and is that work expensive enough to matter?”

That is the question that leads to better frontend performance decisions.

What’s Next?

We’ve now explored how frontend state changes propagate through a component tree and eventually reach the browser.

Many of the expensive calculations we discussed share another important characteristic: sometimes the problem is not that the calculation is too slow, but that we are doing the same calculation repeatedly.

That brings us to another important frontend concept:

Memoization Explained: When Caching Computation Actually Helps

We’ll explore how memoization works, referential equality, memoized components, useMemo, useCallback, selectors, cache invalidation, and why adding memoization everywhere can sometimes make an application more complicated without making it any faster.

Because caching work is useful only when the work was worth avoiding in the first place.

State Management Explained: Why Frontend State Gets Complicated

Billy Okeyo — Fri, 04 Sep 2026 00:00:00 +0000

“State management becomes difficult not because applications have state, but because different kinds of state have different owners, lifetimes, and sources of truth.”

Imagine you’re building a simple product page.

At first, there isn’t much to manage.

const [quantity, setQuantity] = useState(1);

Easy.

Then you add a product variant.

const [selectedColor, setSelectedColor] = useState("black");

Then a modal.

const [isModalOpen, setIsModalOpen] = useState(false);

Then authentication, the shopping cart, filters, pagination, API responses, loading states, and errors. The URL needs to remember the filters, another component needs access to the cart, and when the user navigates away and comes back, some state should remain while other state should disappear.

Before long, your application looks like this:

Frontend Application
       │
       ├── UI State
       ├── Form State
       ├── Server State
       ├── URL State
       ├── Authentication
       ├── Cached Data
       ├── Global State
       └── Derived State

And suddenly someone says:

“We need a state management library.”

But that’s often jumping ahead. Before choosing Redux, Zustand, Pinia, Context, TanStack Query, signals, or anything else, there’s a more important question:

What kind of state are we actually trying to manage?

Not everything called “state” is the same problem, and once you understand that, frontend state management becomes much easier to reason about.

What Is State?

At its simplest, state is information that can change over time and affects what your application does or displays.

Consider a counter:

const [count, setCount] = useState(0);

The UI depends on count.

<button onClick={() => setCount(count + 1)}>
    Count: {count}
</button>

At one moment:

count = 0

After a click:

count = 1

The interface changes because the underlying state changed.

We can think of the UI as a function of state:

State
  │
  ▼
Render
  │
  ▼
UI

Change the state:

New State
    │
    ▼
Re-render
    │
    ▼
New UI

This state-driven model is fundamental to frameworks such as React, Vue, Svelte, and others. The problem isn’t the idea itself. The problem begins when an application has many different sources of changing information.

A Small Application Doesn’t Need “State Management”

Consider a dropdown.

function Dropdown() {
    const [open, setOpen] = useState(false);

    return (
        <div>
            <button onClick={() => setOpen(!open)}>
                Menu
            </button>

            {open && (
                <div>
                    Profile
                    Settings
                    Logout
                </div>
            )}
        </div>
    );
}

The state belongs naturally to the dropdown.

Dropdown
   │
   └── open

Nobody else needs it.

When the dropdown disappears, we probably don’t care about preserving that state.

This is local component state.

And local state is often the best kind of state.

The closer state lives to the code that actually needs it, the easier the application is usually to understand.

The trouble starts when state begins travelling.

When State Needs to Be Shared

Imagine two components:

Header
  │
  └── CartIcon

ProductPage
  │
  └── AddToCartButton

When the user clicks:

Add to Cart

the header needs to update:

Cart (0)
   │
   ▼
Cart (1)

Now the cart state cannot live exclusively inside AddToCartButton. Both components need access to it. A common solution is to move the state upward.

           App
            │
        cartItems
        /       \
       ▼         ▼
   Header    ProductPage
      │           │
 CartIcon    AddToCart

This is commonly called lifting state up: move shared state to a common owner and pass the necessary values or update functions downward. React’s documentation recommends this pattern when multiple components need coordinated state. (React)

That works well.

Until the component tree gets larger.

Prop Drilling Appears

Suppose the structure becomes:

App
 │
 ├── Header
 │    └── Navigation
 │         └── CartButton
 │
 └── Main
      └── ProductPage
           └── ProductDetails
                └── AddToCartButton

The cart state lives in App.

But AddToCartButton needs it.

You may end up passing:

<App>
    <Main cart={cart}>
        <ProductPage cart={cart}>
            <ProductDetails cart={cart}>
                <AddToCartButton cart={cart} />
            </ProductDetails>
        </ProductPage>
    </Main>
</App>

Main doesn’t care about the cart, and ProductPage may not care either. They’re simply transporting information.

App
 │
 │ cart
 ▼
Main
 │
 │ cart
 ▼
ProductPage
 │
 │ cart
 ▼
ProductDetails
 │
 │ cart
 ▼
AddToCartButton

This is commonly called prop drilling, and it’s often the moment developers begin looking for global state management. But before we reach for a global store, we need to make another distinction.

Not All State Is Application State

Consider this dashboard:

┌─────────────────────────────────────┐
│ Dashboard                           │
│                                     │
│ Search: [ laptop             ]      │
│                                     │
│ Status: Active                      │
│                                     │
│ Customers                           │
│ ┌─────────────────────────────────┐ │
│ │ Alice                           │ │
│ │ Billy                           │ │
│ │ James                           │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────┘

What state exists here?

Potentially:

searchText
selectedStatus
customers
isLoading
error
currentUser
sidebarOpen
currentPage

It’s tempting to put all of that into:

Global Store

But those values represent very different things.

For example:

sidebarOpen

belongs to the UI.

While:

customers

probably came from a server.

And:

currentPage

might belong in the URL.

Treating them identically creates unnecessary complexity.

A useful state architecture starts by classifying state.

1. Local UI State

Local UI state represents temporary interaction details.

Examples include:

Modal open?
Dropdown expanded?
Selected tab?
Hovered item?
Accordion expanded?
Tooltip visible?

For example:

const [isOpen, setIsOpen] = useState(false);

This state is usually:

Temporary
Owned by one component or a small subtree
Not important outside that UI
Safe to discard when the component disappears

It should usually stay local.

Modal
  │
  └── isOpen

Moving every boolean into a global store:

store.modalOpen
store.dropdownOpen
store.tooltipVisible
store.settingsTab

can turn a simple application into a state-management bureaucracy.

2. Shared Client State

Some state genuinely needs to be shared across different parts of the application.

Examples might include:

Shopping cart
Application theme
Feature preferences
Complex editor state
Currently selected workspace

Imagine:

             Application
                  │
              Cart State
            /     |      \
           ▼      ▼       ▼
        Header Product Checkout

This is where mechanisms such as:

Context
Redux
Zustand
Pinia
Signals

can become useful depending on the framework and complexity.

The important point is:

Global state should be global because its ownership is global, not because passing props became mildly inconvenient.

3. Server State

Now consider:

const [products, setProducts] = useState([]);

At first glance, this looks like ordinary state.

But where did those products come from?

Probably:

Database
   │
   ▼
Backend
   │
   ▼
API
   │
   ▼
Frontend

The frontend does not actually own this data. The server does, and the browser has a local copy. That creates completely different problems.

Suppose you fetch:

GET /api/products

and receive:

[
    {
        "id": 1,
        "name": "Keyboard",
        "stock": 12
    }
]

Five seconds later, another customer buys two keyboards.

The server now has:

stock = 10

Your frontend still has:

stock = 12

Now your state is stale.

That’s not usually a problem with a modal boolean.

isModalOpen = true

doesn’t suddenly become outdated because another computer changed something.

Server state does.

Server State Has Different Problems

Managing server state means thinking about:

Fetching
Caching
Staleness
Retries
Refetching
Deduplication
Pagination
Mutations
Optimistic updates
Synchronization

Consider:

useEffect(() => {
    fetch("/api/products")
        .then(response => response.json())
        .then(setProducts);
}, []);

Looks simple, until requirements arrive. We need loading state.

const [loading, setLoading] = useState(true);

Then errors.

const [error, setError] = useState(null);

Then retries, caching, refetching when the user returns to the tab, avoiding duplicate requests, and invalidating products after an update.

What looked like:

products

was actually a synchronization problem between:

Server Truth
     │
     ▼
Client Cache
     │
     ▼
UI

That’s why tools such as TanStack Query, SWR, Apollo Client, and framework-native data layers exist. They aren’t simply storing variables. They’re managing remote data lifecycles.

Server State Shouldn’t Automatically Live in Your Global Store

A common architecture used to look like:

API
 │
 ▼
Redux
 │
 ▼
Components

Every API response was copied into the application’s global state.

For some applications, that can still be appropriate.

But often you’re making your client store responsible for problems that a server-state cache is specifically designed to solve.

A modern architecture may instead look like:

                Frontend
                   │
        ┌──────────┴──────────┐
        │                     │
        ▼                     ▼
 Client State            Server State
        │                     │
    Zustand /             Query Cache
     Redux /                  │
    Context                   ▼
                         Backend API

Different problems.

Different tools.

4. URL State

Suppose your product page has filters:

Category: Laptops
Price: 20,000 - 100,000
Sort: Price Low to High
Page: 3

You could store them as:

const [category, setCategory] = useState("laptops");
const [sort, setSort] = useState("price");
const [page, setPage] = useState(3);

But what happens when the user refreshes? The state disappears. What happens when they copy the URL and send it to someone? The other person sees the default filters. What happens when they press the browser’s Back button? Potentially, nothing useful. Maybe this state belongs somewhere else: the URL.

/products?category=laptops&sort=price&page=3

Now:

URL
 │
 ├── category=laptops
 ├── sort=price
 └── page=3

becomes the source of truth.

This gives us useful behavior almost automatically:

Refresh        ✓
Share link     ✓
Bookmark       ✓
Back button    ✓
Forward button ✓

This is why the URL itself should be thought of as a state container.

Don’t Duplicate URL State

A common mistake is:

URL
 │
 └── page=3

AND

React State
 │
 └── page=3

Now you have two sources of truth.

What happens if:

URL page = 3

but

React page = 2

Which one wins?

You’ve created a synchronization problem that didn’t need to exist.

A better model is:

URL
 │
 ▼
page
 │
 ▼
UI

If the URL owns the value, read it from there.

5. Form State

Forms deserve their own category because they can become surprisingly complicated.

A simple form:

const [email, setEmail] = useState("");

is easy.

Now add:

Name
Email
Phone
Country
Address
Password
Confirm Password

Then:

Validation
Touched fields
Dirty fields
Submitting
Server errors
Conditional fields
Resetting
Default values

Suddenly, “email” isn’t the only state.

You have:

value
valid?
touched?
dirty?
error?
submitting?

for potentially dozens of fields.

That’s why libraries such as React Hook Form, Formik, and framework-specific form systems exist.

Again, the lesson isn’t:

Use a library for every form.

It’s:

Recognize that form state has a particular lifecycle and shouldn’t automatically become global application state.

6. Derived State

Derived state is one of the most common sources of unnecessary complexity.

Imagine:

const [firstName, setFirstName] = useState("Billy");
const [lastName, setLastName] = useState("Okeyo");
const [fullName, setFullName] = useState("Billy Okeyo");

We now have three pieces of state.

But do we really?

fullName can be calculated:

const fullName = `${firstName} ${lastName}`;

So our actual state is:

firstName
lastName

and:

fullName

is derived.

React’s own guidance recommends avoiding redundant state when a value can be calculated from existing props or state during rendering. (React)

Why?

Because duplication creates synchronization problems.

The Synchronization Trap

Suppose we store all three:

const [firstName, setFirstName] = useState("Billy");
const [lastName, setLastName] = useState("Okeyo");
const [fullName, setFullName] = useState("Billy Okeyo");

Now someone writes:

setFirstName("John");

but forgets:

setFullName("John Okeyo");

We get:

firstName = John
lastName  = Okeyo
fullName  = Billy Okeyo

Your application contradicts itself.

The problem isn’t React.

The problem is that we stored information that could have been calculated.

A good rule is:

Store the minimum information required to describe the application. Derive everything else.

React describes this as finding the minimal but complete representation of UI state. (React)

Another Derived State Example

Suppose:

const [products, setProducts] = useState([...]);
const [search, setSearch] = useState("");

Should we also store:

const [filteredProducts, setFilteredProducts] = useState([]);

Probably not.

We can derive it:

const filteredProducts = products.filter(product =>
    product.name
        .toLowerCase()
        .includes(search.toLowerCase())
);

Our model becomes:

products ──────┐
               │
               ▼
             Filter ───► filteredProducts
               ▲
               │
search ─────────┘

filteredProducts is an output.

Not necessarily state.

State Gets Complicated When We Duplicate Truth

This is one of the biggest themes in frontend state management.

Imagine:

API Response
    │
    ├── Redux Store
    │
    ├── Component State
    │
    ├── Form State
    │
    └── localStorage

Now the same information exists in four places.

Every update creates a question:

Which one is correct?

Then:

Which one should update first?

Then:

What if one update fails?

Then:

What happens after refresh?

A large percentage of state-management complexity is actually state synchronization complexity.

The fewer copies of truth you maintain, the fewer things you need to synchronize.

Impossible States

Poorly structured state can also represent combinations that should never exist.

Consider:

const [isLoading, setIsLoading] = useState(false);
const [isSuccess, setIsSuccess] = useState(false);
const [isError, setIsError] = useState(false);

Nothing technically prevents:

isLoading = true
isSuccess = true
isError   = true

But what does that mean?

We’re loading successfully while failing?

Instead, maybe the application actually has one state:

const [status, setStatus] = useState("idle");

with possible values:

idle
loading
success
error

Now:

status = loading

cannot simultaneously be:

status = success

The data structure itself prevents invalid combinations. React’s state-structure guidance specifically recommends avoiding contradictory state for this reason. (React)

This idea becomes extremely powerful in complex UIs.

Think in State Machines

Consider a payment flow.

You might start with:

const [loading, setLoading] = useState(false);
const [paid, setPaid] = useState(false);
const [failed, setFailed] = useState(false);
const [cancelled, setCancelled] = useState(false);

But conceptually, the payment probably behaves more like:

            ┌───────────┐
            │   IDLE    │
            └─────┬─────┘
                  │ Pay
                  ▼
            ┌───────────┐
            │PROCESSING │
            └─────┬─────┘
                  │
          ┌───────┼────────┐
          ▼       ▼        ▼
      SUCCESS   FAILED   CANCELLED

Representing it as:

const [status, setStatus] = useState("idle");

makes the model much closer to reality.

Good state management often starts with good data modelling, not better libraries.

State Ownership Matters

Imagine three components:

ProductPage
 ├── ProductGallery
 ├── ProductDetails
 └── AddToCart

Only ProductGallery needs:

currentImage

Where should it live?

Probably:

ProductGallery
      │
      └── currentImage

Not:

Global Store
      │
      └── currentImage

Now suppose both ProductDetails and AddToCart need:

selectedVariant

Then perhaps:

ProductPage
      │
      └── selectedVariant
             │
        ┌────┴─────┐
        ▼          ▼
ProductDetails  AddToCart

State should generally live at the lowest level that owns all consumers that need it.

Move it upward when necessary.

Not before.

State Lifetime Matters Too

Different state should survive for different amounts of time.

Consider:

Tooltip open

Lifetime:

Seconds

Shopping cart:

Minutes / Days

Authentication session:

Hours / Days

URL filter:

As long as URL exists

Server cache:

Until stale / invalidated

User preferences:

Months

Putting all of these into one store ignores their fundamentally different lifecycles.

A useful way to think about state is:

State
 │
 ├── Who owns it?
 │
 ├── Who needs it?
 │
 ├── How long should it live?
 │
 ├── Where is the source of truth?
 │
 └── What causes it to change?

Answer those questions first.

Then choose the storage mechanism.

Persistence Is Not the Same as State Management

Suppose we want the theme to survive refreshes.

We might use:

localStorage.setItem("theme", "dark");

Now some developers immediately put all application state into localStorage.

But persistence creates another source of truth.

Application State
       │
       ▼
localStorage

What happens when the application’s expected data structure changes? What happens when the stored value is invalid? What happens when the user logs out? What happens when data becomes stale? Persistence should be intentional. Not every state deserves immortality.

Context Is Not Automatically a State Manager

In React, Context is often introduced when prop drilling becomes uncomfortable.

<CartContext.Provider value={cart}>
    <App />
</CartContext.Provider>

Then:

const cart = useContext(CartContext);

This solves a distribution problem.

Instead of:

App
 │ props
 ▼
A
 │ props
 ▼
B
 │ props
 ▼
C

we get:

      Context
      /  |  \
     ▼   ▼   ▼
     A   B   C

That’s useful.

But Context doesn’t automatically solve:

Caching
Server synchronization
Persistence
Complex update logic
Optimistic updates
Normalized entities

It’s a mechanism for making values available through a component tree. Sometimes that’s all you need. Sometimes it isn’t.

Why Global Stores Exist

As applications grow, some client state can become genuinely complicated.

Imagine an image editor.

Canvas
 │
 ├── Selected objects
 ├── Layers
 ├── History
 ├── Zoom
 ├── Tools
 ├── Clipboard
 └── Document state

Many distant components may need to read and modify the same information.

              Editor State
          /       |       \
         ▼        ▼        ▼
      Toolbar   Canvas   Layers
         │        │        │
         ▼        ▼        ▼
      Buttons   Objects   Panel

A centralized or shared store can provide:

One ownership model
Predictable updates
Subscriptions
Selectors
Debugging tools
Middleware

This is where Redux, Zustand, Pinia and similar solutions can shine. The problem isn’t global state. The problem is unnecessarily global state.

Redux Isn’t the Answer to Every State Problem

Suppose your application has:

const [modalOpen, setModalOpen] = useState(false);

Moving it into Redux:

dispatch(openModal());

doesn’t automatically improve the architecture.

Likewise, storing an API response in Redux doesn’t automatically solve server-state caching.

And storing filters in Redux may be worse than putting them in the URL.

Instead of asking:

Which state library should we use?

Ask:

Where should this specific piece of state live?

Then the answer may be:

Component
URL
Server cache
Form manager
Context
Global store
Browser storage

The tool follows the ownership model.

A Better State Architecture

Imagine an e-commerce application.

Instead of:

EVERYTHING
    │
    ▼
Redux

we might have:

                    Application
                         │
       ┌─────────────────┼─────────────────┐
       │                 │                 │
       ▼                 ▼                 ▼
   UI State          URL State        Server State
       │                 │                 │
    useState           Router          Query Cache
       │                                   │
       ▼                                   ▼
 Components                              API

                         │
                         ▼
                  Shared Client State
                         │
                         ▼
                    Global Store

Now each type of state uses the mechanism suited to its job.

This can actually make an application simpler even though we’re using several different tools.

Because each tool has a clear responsibility.

Example: Building a Product Search Page

Let’s put this into practice.

Suppose we’re building:

/products

The page contains:

Search
Category filter
Sort order
Products
Cart
Filter drawer

Where should everything live?

Filter Drawer

isFilterDrawerOpen

This is local UI state.

const [isFilterDrawerOpen, setFilterDrawerOpen] =
    useState(false);

Search and Filters

These affect what page the user is viewing and should be shareable.

/products?q=keyboard&category=accessories&sort=price

So:

URL State

is a strong choice.

Products

Products come from:

Backend API

So they’re:

Server State

A query cache could manage them.

Conceptually:

useQuery({
    queryKey: ["products", search, category, sort],
    queryFn: fetchProducts
});

Shopping Cart

The cart may be needed by:

Header
Product Page
Checkout
Sidebar

This could be:

Shared Client State

or server state depending on how the cart is persisted and synchronized.

That’s an architectural decision.

Number of Products

Suppose we already have:

products

Don’t necessarily store:

productCount

Just derive:

const productCount = products.length;

Now our architecture is much clearer:

Product Search Page
       │
       ├── Filter drawer ──► Local State
       │
       ├── Search ─────────► URL
       │
       ├── Category ───────► URL
       │
       ├── Sort ───────────► URL
       │
       ├── Products ───────► Server Cache
       │
       ├── Cart ───────────► Shared State
       │
       └── Product Count ──► Derived

That’s state management.

Notice that we haven’t needed one giant store.

Why State Libraries Sometimes Make Things Worse

Suppose a team decides:

“Everything goes in Redux.”

Now adding a modal requires:

Action
Reducer
Selector
Dispatch
Store

even though:

useState(false)

would have solved the problem.

Or the team puts every API response into the store and manually implements:

Loading
Caching
Retries
Invalidation
Staleness

They end up rebuilding a server-state library.

Or they store pagination in global state and then write custom logic to synchronize it with the URL.

They’ve now created:

URL
  ↕
Redux
  ↕
Components

when:

URL
  ↓
Components

would have been simpler.

More powerful tools don’t automatically create simpler architecture.

Why State Libraries Sometimes Make Things Much Better

The opposite mistake is pretending every application can survive indefinitely on:

useState + props

Imagine a complex trading interface.

Dozens of components need access to:

Selected instrument
Open positions
Workspace layout
Active panels
Watchlists
Notifications
User preferences

Trying to thread everything through component hierarchies can become difficult.

A well-designed store can create:

                 Store
        ┌──────────┼──────────┐
        ▼          ▼          ▼
     Chart      Orders     Watchlist

Components subscribe only to the state they need.

The state transitions can be centralized and inspected.

The lesson isn’t:

Global stores are bad.

It’s:

Use global stores for genuinely shared
client-side state.

State and Re-Renders

State architecture also affects rendering performance.

Suppose a global context contains:

{
    user,
    cart,
    theme,
    notifications,
    sidebar,
    preferences
}

A change to:

sidebar

may cause consumers of that context to re-evaluate even if they only care about:

user

depending on how the architecture is implemented.

This is one reason state libraries often provide selectors.

Conceptually:

Global Store
    │
    ├── Component A subscribes to cart
    │
    ├── Component B subscribes to user
    │
    └── Component C subscribes to theme

When:

cart changes

we ideally want to notify only consumers that care about the cart. State management isn’t only about storing information. It’s also about efficiently distributing changes.

State Has Identity

There’s another subtle issue.

Consider:

const user = {
    name: "Billy"
};

Then:

const anotherUser = {
    name: "Billy"
};

Their contents look identical.

But:

user === anotherUser

is:

false

because they’re different objects.

This matters in reactive systems because object identity can influence:

Change detection
Memoization
Dependencies
Selectors
Re-renders

Carelessly recreating objects can therefore produce unnecessary updates. State management isn’t only about what values exist. Sometimes it’s also about whether the system considers those values changed.

Immutable Updates

React developers often encounter patterns such as:

setUser({
    ...user,
    name: "John"
});

instead of:

user.name = "John";

Why?

Because frameworks need reliable ways to understand that state changed.

With immutable-style updates:

Old State
   │
   ▼
Create New State
   │
   ▼
New Reference

the transition is easier to reason about.

For arrays:

setProducts(
    products.map(product =>
        product.id === updated.id
            ? updated
            : product
    )
);

rather than mutating the existing array.

Different frameworks have different reactivity models, but the broader principle remains:

Understand how your framework detects change.

Deeply Nested State Gets Painful

Consider:

const state = {
    user: {
        profile: {
            address: {
                city: "Nairobi"
            }
        }
    }
};

Updating the city immutably can become awkward:

setState({
    ...state,
    user: {
        ...state.user,
        profile: {
            ...state.user.profile,
            address: {
                ...state.user.profile.address,
                city: "Mombasa"
            }
        }
    }
});

The problem is partly the update syntax.

But it’s also the state shape.

React’s guidance suggests flattening deeply nested state where practical because it makes updates easier and helps reduce duplication. (React)

Instead of thinking only:

How do I update this deeply nested object?

sometimes ask:

Should my state be shaped like this in the first place?

State Should Have a Source of Truth

Suppose a user’s name exists in:

Server
Redux
Header component
Profile form
localStorage

That’s five versions of:

Billy

Now the profile is changed.

Billy
  │
  ▼
William

Which copies update?

Server          William
Redux           William
Header          Billy
Profile Form    William
localStorage    Billy

Now the UI disagrees with itself.

A better architecture clearly defines:

Source of Truth
      │
      ▼
Other representations

For example:

Server
  │
  ▼
Query Cache
  │
  ├── Header
  ├── Profile
  └── Settings

One authoritative source.

Multiple consumers.

The State Management Decision Tree

Before adding state, ask:

Can this value be calculated from existing information?

If yes:

Derive it.

If no:

Does only one component need it?

If yes:

Keep it local.

If multiple nearby components need it:

Lift it to their common owner.

If it represents navigation or shareable page configuration:

Consider the URL.

If it came from a backend:

Treat it as server state.

If it’s complex form interaction:

Treat it as form state.

If it’s genuinely shared client information:

Consider Context or a store.

If it must survive sessions:

Consider persistence deliberately.

The process looks like:

                   New State
                       │
                       ▼
              Can it be derived?
                 /           \
               Yes            No
                │              │
             Derive       Who owns it?
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
          Component          URL            Server
              │                               │
              ▼                               ▼
         Local State                     Query Cache

                 Shared broadly?
                       │
                       ▼
                  Global Store

The Best State Is Often No State

This sounds strange in an article about state management.

But one of the strongest state-management techniques is simply removing unnecessary state.

Instead of:

const [items, setItems] = useState([]);
const [itemCount, setItemCount] = useState(0);
const [hasItems, setHasItems] = useState(false);

store:

const [items, setItems] = useState([]);

and derive:

const itemCount = items.length;
const hasItems = items.length > 0;

We’ve gone from:

3 synchronized variables

to:

1 source of truth

React’s documentation emphasizes avoiding redundant and duplicate state precisely because fewer independent pieces of state are easier to keep consistent. (React)

That’s a lesson that applies far beyond React.

Bringing It All Together

Frontend state becomes complicated because we’re often using the word state to describe many different problems.

                     STATE
                       │
       ┌───────────────┼────────────────┐
       │               │                │
       ▼               ▼                ▼
   UI State        Server State      URL State
       │               │                │
       ▼               ▼                ▼
 Component          Query Cache        Router

       ┌───────────────┼────────────────┐
       │               │                │
       ▼               ▼                ▼
  Form State      Shared State     Derived Data
       │               │                │
       ▼               ▼                ▼
 Form Manager      Global Store      Calculate

Trying to force all of these into one state-management solution creates complexity.

The better approach is to understand the ownership and lifecycle of each value.

Ask:

Where did this value come from?

Who owns it?

Who needs it?

How long should it live?

Can it be derived?

Does it need to survive navigation?

Does it belong in the URL?

Is the server actually the source of truth?

Once those questions are answered, the technology choice becomes much easier.

Final Thoughts

State management is often presented as a library problem. React developers debate Redux versus Zustand, Vue developers discuss Pinia, and other ecosystems introduce signals, stores, atoms, observables, and new reactive primitives. Those tools matter, but they come after the more important architectural decision.

You first need to model your state correctly. A badly designed state model doesn’t become good because you put it into Redux. Duplicated state doesn’t stop being duplicated because Zustand stores it. Server state doesn’t stop becoming stale because Context distributes it. And a filter that belongs in the URL doesn’t suddenly belong somewhere else because your state library has persistence.

Good frontend state management is mostly about maintaining clear ownership and minimizing sources of truth.

So instead of beginning with:

“Which state management library should we use?”

begin with:

“What kind of state is this, and where does it naturally belong?”

That question solves far more problems.

What’s Next?

So far in Beyond the UI, we’ve moved through several layers of the frontend:

Browser Rendering Pipeline
          │
          ▼
Reflow and Repaint
          │
          ▼
JavaScript Event Loop
          │
          ▼
CSR vs SSR
          │
          ▼
Hydration
          │
          ▼
State Management

We’ve now seen how the browser renders an application, how JavaScript gets scheduled, how applications can be rendered on the server, how hydration makes them interactive, and how their changing data can be organized.

But there’s another performance problem hiding inside modern frontend applications. You update one small piece of state:

setCount(count + 1);

and suddenly multiple components execute again. Why? What does “re-render” actually mean? Does re-rendering mean the DOM was rebuilt? When does React actually touch the browser DOM? And when should you use tools such as memo, useMemo, and useCallback?

That’s where we’ll go next:

Re-Renders Explained: What Actually Happens When Frontend State Changes

Because before trying to prevent re-renders, you need to understand what a re-render actually costs.

Hydration Explained: How Server-Rendered Pages Become Interactive

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

“Server-side rendering can make a page visible before JavaScript arrives. Hydration is what turns that visible HTML into an interactive application.”

In the previous article in Beyond the UI, we compared Client-Side Rendering and Server-Side Rendering.

With Client-Side Rendering, the browser might initially receive something as small as:

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

JavaScript then constructs the interface in the browser.

With Server-Side Rendering, the server can send meaningful HTML immediately:

<article class="product">
    <h1>Mechanical Keyboard</h1>
    <p>KES 12,000</p>

    <button>
        Add to Cart
    </button>
</article>

The browser can parse and display that HTML without waiting for React, Vue, or another framework to construct it.

That sounds like the problem is solved. The user can see the product, the button is visible, and the page looks complete. But then the user clicks:

Add to Cart

and nothing happens. Why?

Because HTML can describe the button, but the server-rendered document doesn’t automatically contain the JavaScript behavior that your application expects.

The browser may know:

There is a button here.

But your framework still needs to establish:

When this button is clicked,
update the shopping cart.

That transition, from server-rendered HTML to interactive application, is where hydration comes in.

At a high level:

Server
   │
   ▼
Render Components
   │
   ▼
HTML
   │
   ▼
Browser Displays HTML
   │
   ▼
JavaScript Loads
   │
   ▼
Hydration
   │
   ▼
Interactive Application

Hydration sounds simple, but it introduces some of the most interesting performance and architecture challenges in modern frontend development. So let’s follow a page through the process.

First, What Exactly Is Hydration?

Hydration is the process through which client-side JavaScript attaches application behavior to HTML that was already rendered on the server.

Imagine a React component:

function Counter() {
    const [count, setCount] = useState(0);

    return (
        <button onClick={() => setCount(count + 1)}>
            Count: {count}
        </button>
    );
}

When server-rendered, the browser may initially receive:

<button>
    Count: 0
</button>

That’s perfectly valid HTML. The browser can display it.

┌────────────────┐
│    Count: 0    │
└────────────────┘

But the HTML response itself doesn’t contain React’s setCount function or the component’s runtime state. The browser still needs the relevant JavaScript. Once that JavaScript arrives, React can connect the existing DOM to the application.

Conceptually:

Existing HTML

<button>
    Count: 0
</button>

        +

Client JavaScript

Counter()
useState()
onClick()

        │
        ▼

     Hydration

        │
        ▼

Interactive Button

After hydration, clicking the button can update the state:

Count: 0
   │
   │ click
   ▼
Count: 1

The key idea is that the framework isn’t necessarily throwing away the server-generated HTML and starting again. It attempts to reuse the existing DOM and attach the behavior needed to make it interactive.

Why Do We Need Hydration?

Why not simply let the server render the page and leave it there? For some websites, that’s perfectly reasonable. A simple article might require almost no JavaScript. But modern applications often contain interactions such as:

Add to Cart
Like Post
Open Modal
Submit Form
Filter Results
Expand Menu
Update Counter
Drag Item
Search

Those interactions require application logic somewhere.

For example:

function AddToCart({ product }) {
    const [adding, setAdding] = useState(false);

    async function addToCart() {
        setAdding(true);

        await api.addToCart(product.id);

        setAdding(false);
    }

    return (
        <button onClick={addToCart}>
            {adding ? "Adding..." : "Add to Cart"}
        </button>
    );
}

The server can render:

<button>
    Add to Cart
</button>

But the browser still needs the JavaScript responsible for:

Click
  │
  ▼
Set loading state
  │
  ▼
Call API
  │
  ▼
Update cart
  │
  ▼
Update button

Hydration bridges the gap between HTML generated elsewhere and behavior running in the browser.

The Full Server-Rendering Journey

Let’s look at the entire process. Suppose a user requests:

/products/42

The server receives the request.

Browser
   │
   │ GET /products/42
   ▼
Server

The server fetches the product:

const product = await database.products.findById(42);

It renders the application:

<ProductPage product={product} />

which becomes HTML:

<main>
    <h1>Mechanical Keyboard</h1>

    <p>KES 12,000</p>

    <button>
        Add to Cart
    </button>
</main>

The response reaches the browser. Now everything we’ve discussed earlier in this series begins happening.

HTML
 │
 ▼
DOM
 │
 ▼
Layout
 │
 ▼
Paint
 │
 ▼
Pixels

The user sees the page. Meanwhile, JavaScript required by the application is downloaded.

HTML visible
     │
     ├──────────────► User sees content
     │
     ▼
JavaScript downloads
     │
     ▼
JavaScript parses
     │
     ▼
JavaScript executes
     │
     ▼
Hydration
     │
     ▼
Application interactive

This creates an important distinction. A page can be:

Visible

without yet being:

Fully interactive

Visible Does Not Mean Interactive

This is one of the most important concepts to understand about hydration.

Imagine the following timeline:

0ms
User requests page

      │
      ▼

300ms
HTML arrives

      │
      ▼

400ms
Content visible

      │
      ▼

800ms
JavaScript downloaded

      │
      ▼

1100ms
JavaScript executed

      │
      ▼

1300ms
Hydration completed

Between roughly:

400ms → 1300ms

the page may look ready.

The user can see:

Product

Mechanical Keyboard

KES 12,000

[ Add to Cart ]

But depending on the application and framework behavior, the client-side interaction may not yet be ready. The user sees a button. Naturally, they click it. If the required JavaScript hasn’t become operational yet, that interaction can be delayed or require special handling by the framework.

This creates an interesting UX problem:

A page can visually promise interactivity before it is ready to deliver it.

Hydration Is Not Free

SSR is sometimes described as though it simply moves rendering from the browser to the server. But with traditional hydration-heavy architectures, the browser can still have significant work to perform.

Consider this application:

Server
   │
   ▼
Render React Application
   │
   ▼
Send HTML

Then:

Browser
   │
   ├── Parse HTML
   ├── Render page
   ├── Download React
   ├── Download application JS
   ├── Parse JavaScript
   ├── Execute JavaScript
   └── Hydrate application

The server rendered the interface. But the browser may still need much of the JavaScript representation of that application so the framework can make it interactive.

In simplified form:

SERVER                         CLIENT

Render Components
       │
       ▼
      HTML ──────────────────► Display HTML
                                │
JavaScript ──────────────────► Download
                                │
                                ▼
                              Parse
                                │
                                ▼
                             Execute
                                │
                                ▼
                             Hydrate

For a small application, this may be cheap. For a large application, hydration can involve a significant amount of work.

The Double-Work Problem

This leads to one criticism of traditional hydration architectures.

The server does work:

Components
    │
    ▼
HTML

Then the client receives JavaScript describing much of the same application and performs additional work to reconstruct the application’s runtime representation and connect it to the existing DOM.

Conceptually:

SERVER

Component Tree
     │
     ▼
HTML


CLIENT

HTML
 +
Component JavaScript
 +
Application State
     │
     ▼
Hydration

The server rendering was useful because the user received content earlier. But the client hasn’t escaped JavaScript execution.

In some architectures, we’ve effectively said:

“Render this application on the server so users can see it quickly, then send enough JavaScript for the browser to understand much of that application again.”

This trade-off becomes increasingly noticeable as applications grow.

A React Hydration Example

Consider a small server-rendered React application.

On the server, conceptually:

const html = renderToString(<App />);

The resulting HTML is sent to the browser.

On the client, instead of creating a completely new DOM tree with:

createRoot(root).render(<App />);

a server-rendered React application can hydrate the existing DOM:

import { hydrateRoot } from "react-dom/client";

hydrateRoot(
    document.getElementById("root"),
    <App />
);

The distinction is important.

createRoot() effectively says:

Build this client application in this root.

hydrateRoot() says:

There is already server-generated HTML here. Connect React to it.

Conceptually:

Server HTML

<div id="root">
    <button>Count: 0</button>
</div>

        │
        ▼

hydrateRoot(...)

        │
        ▼

React connects to
existing DOM

        │
        ▼

Interactive Application

This works well when the client expects the same interface the server produced. But what happens when it doesn’t?

Hydration Mismatches

Suppose the server renders:

<p>Welcome back, Billy</p>

but when the client begins hydrating, React expects:

<p>Welcome back, Guest</p>

Now the server and client disagree. This is a hydration mismatch.

Conceptually:

SERVER HTML

Welcome back, Billy

        ≠

CLIENT EXPECTATION

Welcome back, Guest

Frameworks may warn about this because hydration depends on the initial server and client output being compatible. A mismatch can cause the framework to repair or re-render portions of the UI, and it can lead to confusing bugs.

How Hydration Mismatches Happen

Some mismatches are surprisingly easy to create.

Consider:

function CurrentTime() {
    return <p>{new Date().toLocaleTimeString()}</p>;
}

The server renders at:

10:42:01

By the time the browser hydrates:

10:42:03

The output may differ.

Another classic example is random values:

function Identifier() {
    return <p>{Math.random()}</p>;
}

The server might produce:

0.21843

while the client produces:

0.79216

That’s a mismatch.

Browser-only information can cause similar problems.

window.innerWidth
localStorage
navigator.language

Those values may not exist on the server or may differ from what the server assumed.

A More Subtle Example: Authentication

Suppose the server knows the user is authenticated. It renders:

<nav>
    <span>Welcome Billy</span>
    <button>Logout</button>
</nav>

But your client-side authentication store initially starts with:

const user = null;

The client expects:

<nav>
    <button>Login</button>
</nav>

Again:

Server
   │
   └── Authenticated

Client initial state
   │
   └── Not authenticated

        ↓

Hydration mismatch

The solution is often to make sure the initial client state is derived from the same data used to generate the server output.

Conceptually:

Server Data
    │
    ├── Render HTML
    │
    └── Serialize initial state
              │
              ▼
            Client
              │
              ▼
           Hydration

The server and client need to agree about what the initial page represents.

Why Hydration Can Become Expensive

Imagine a large e-commerce homepage containing:

Header
Navigation
Search
Hero
Recommendations
Categories
Products
Reviews
Newsletter
Footer

Suppose only a few parts are actually interactive:

Search
Cart
Product carousel
Newsletter form

With a traditional full-page hydration model, the browser may still receive JavaScript for a much larger component tree.

Conceptually:

Page
│
├── Header
├── Navigation
├── Hero
├── Categories
├── Products
├── Reviews
├── Newsletter
└── Footer

        │
        ▼

Hydrate Everything

But much of the page may simply be content. The hero doesn’t necessarily need client-side JavaScript, the footer probably doesn’t need React state, and a product description may never change after rendering. So why hydrate everything?

That question has driven several newer frontend architecture ideas.

Partial Hydration

Instead of hydrating the entire page, what if we hydrate only the interactive parts?

Imagine:

Page
│
├── Header
│
├── Search ◄──── HYDRATE
│
├── Hero
│
├── Product Grid
│
├── Cart Button ◄ HYDRATE
│
├── Article Content
│
└── Footer

Now static content remains HTML. Interactive pieces receive JavaScript.

Conceptually:

Server HTML
│
├── Static
├── Static
├── Interactive Island + JS
├── Static
├── Interactive Island + JS
└── Static

This is broadly the idea behind partial hydration and related “islands” architectures.

The goal is straightforward:

Don’t ship JavaScript for parts of the page that don’t need JavaScript.

Islands Architecture

Astro is well known for popularizing this model.

Imagine a page:

┌───────────────────────────────────────┐
│              Header                   │
├───────────────────────────────────────┤
│                                       │
│          Static Article               │
│                                       │
│       No client JS required           │
│                                       │
├───────────────────────────────────────┤
│       Interactive Comments            │ ◄── JS
├───────────────────────────────────────┤
│              Footer                   │
└───────────────────────────────────────┘

The interactive component becomes an island inside mostly static HTML.

Instead of:

Entire Page
    │
    ▼
Hydrate Everything

we get:

Static HTML
    │
    ├── Interactive Island
    │        │
    │        ▼
    │     Hydrate
    │
    └── Static HTML

For content-heavy sites, this can dramatically reduce the amount of client JavaScript required.

Lazy Hydration

Even when a component needs JavaScript, it doesn’t necessarily need it immediately. Consider a comments section at the bottom of a long article. The user might never scroll that far. Hydrating it immediately means spending resources on something the user may never interact with. Instead, hydration can be delayed until a condition is met.

For example:

Page Loads
    │
    ▼
Comments not visible
    │
    ▼
Do nothing
    │
    │
User scrolls
    │
    ▼
Comments approach viewport
    │
    ▼
Load / Hydrate

Other triggers could include:

When visible
When browser is idle
When user interacts
After important content is ready

This shifts hydration from:

Hydrate everything now.

to:

Hydrate something when there’s a reason to.

Selective Hydration

Another approach is selective hydration.

Suppose a page has several sections waiting to hydrate.

Header
Product Details
Reviews
Recommendations
Footer

The user clicks something in the header before everything else has completed. Instead of requiring hydration to proceed strictly from top to bottom, a framework can prioritize the part relevant to the user’s interaction.

Conceptually:

Hydration Queue

Product Details
Reviews
Recommendations
Header
Footer

User clicks Header

        │
        ▼

Prioritize Header

The broader principle is important:

Not all parts of a page are equally urgent.

Modern rendering architectures increasingly try to schedule work according to what matters most to the user.

Streaming Makes Things Even More Interesting

Traditional SSR can look like:

Request
   │
   ▼
Fetch EVERYTHING
   │
   ▼
Render EVERYTHING
   │
   ▼
Send HTML

If one slow data source takes two seconds, the entire page might wait. Streaming SSR allows the server to begin sending useful parts of the page earlier.

Conceptually:

Request
   │
   ▼
Server

Header ready ───────────────► Browser

Main content ready ─────────► Browser

Recommendations still loading...

Recommendations ready ──────► Browser

Instead of one giant response arriving after everything is complete, HTML can arrive progressively. Combine that with modern hydration techniques and you get something closer to:

HTML arrives
     │
     ▼
Content appears
     │
     ▼
More HTML streams
     │
     ▼
Relevant JavaScript arrives
     │
     ▼
Interactive regions hydrate

The line between “loading” and “loaded” becomes much less binary.

React Server Components Change the Question

React Server Components take a more fundamental approach.

Consider:

function ProductDescription({ product }) {
    return (
        <section>
            <h1>{product.name}</h1>
            <p>{product.description}</p>
        </section>
    );
}

If this component doesn’t need:

State
Effects
Browser APIs
Event handlers

why does its component JavaScript need to run in the browser? With Server Components, it may not.

Conceptually:

SERVER

ProductDescription
Reviews
ProductDetails

        │
        ▼

Rendered representation

        │
        ▼

CLIENT

AddToCartButton
Search
Cart

Only components that require client-side behavior need to become part of the browser’s interactive JavaScript application.

This changes the conversation from:

How do we hydrate the entire server-rendered application efficiently?

toward:

How much of this application needs hydration at all?

That’s a much more powerful question.

Server Components vs Hydration

It’s worth separating the concepts.

A traditional server-rendered client component might go through:

Server Render
     │
     ▼
HTML
     │
     ▼
Browser
     │
     ▼
Hydration

A server-only component doesn’t need to become an interactive client component.

Server Component
     │
     ▼
Server
     │
     ▼
Rendered output
     │
     ▼
Browser

No equivalent component
JavaScript required
for hydration

But interactive client components still need browser JavaScript.

For example:

"use client";

function AddToCart() {
    const [quantity, setQuantity] = useState(1);

    return (
        <button onClick={() => add(quantity)}>
            Add to Cart
        </button>
    );
}

So a modern page may contain both:

Server Components
       │
       └── No client hydration for their component logic

Client Components
       │
       └── Need client-side JavaScript / hydration

Again, modern frontend architecture is increasingly about choosing boundaries.

Hydration and the Main Thread

Now let’s connect hydration to our previous article on the JavaScript event loop.

Suppose the browser downloads a large JavaScript bundle. It needs to:

Download
   │
   ▼
Parse
   │
   ▼
Compile
   │
   ▼
Execute
   │
   ▼
Hydrate

Much of that work interacts with the browser’s main thread.

If hydration becomes expensive:

Main Thread

┌──────────────────────────────┐
│      JavaScript              │
├──────────────────────────────┤
│      Hydration               │
├──────────────────────────────┤
│      More Hydration          │
└──────────────────────────────┘

user interactions may have to compete with that work.

Remember our earlier lesson:

A page can look ready while JavaScript is still occupying the main thread.

This is why shipping less JavaScript isn’t merely about reducing network transfer.

It can also mean:

Less parsing
Less compilation
Less execution
Less hydration
Less main-thread work

The network is only part of the cost.

Hydration and the Rendering Pipeline

Hydration also connects directly to our first two articles. Hydration may update DOM state, DOM updates can invalidate styles, some updates may trigger layout, and layout changes may require painting. So the full picture can become:

Server HTML
     │
     ▼
Browser Parses HTML
     │
     ▼
Initial Render
     │
     ▼
JavaScript Loads
     │
     ▼
Hydration
     │
     ▼
DOM / State Updates
     │
     ▼
Style
     │
     ▼
Layout
     │
     ▼
Paint
     │
     ▼
Composite

The concepts in this series aren’t isolated. They form one system.

Why Huge JavaScript Bundles Hurt SSR Too

Imagine two applications. Both server-render their HTML in:

300ms

Application A sends:

80 KB JavaScript

Application B sends:

2 MB JavaScript

Both might display meaningful content quickly. But the browser still has very different workloads.

Application A

HTML
 │
 ▼
Small JS
 │
 ▼
Hydrate
 │
 ▼
Interactive


Application B

HTML
 │
 ▼
Large JS
 │
 ▼
Download
 │
 ▼
Parse
 │
 ▼
Execute
 │
 ▼
Hydrate
 │
 ▼
Interactive

This is why saying:

“We’re using SSR, so initial performance is solved.”

can be misleading. SSR addresses only part of the journey.

What About Event Handlers?

A common simplified explanation of hydration says:

“Hydration attaches event listeners to server-rendered HTML.”

That’s useful as an introduction, but hydration generally involves more than literally walking through every element and calling addEventListener. Frameworks have different event systems and hydration strategies. For example, React uses event delegation for many events.

The more accurate mental model is:

Hydration connects server-rendered DOM with the client framework’s runtime representation so that state, events, and future updates can behave correctly.

Think:

Static Server DOM

        +

Client Application Runtime

        │
        ▼

Connected Interactive UI

rather than simply:

HTML + click handlers

Hydration Errors Are Architecture Clues

When developers encounter hydration warnings, the instinct is often to silence them. But a mismatch can reveal an architectural problem.

For example:

function Theme() {
    const theme = localStorage.getItem("theme");

    return <div className={theme}>...</div>;
}

This code assumes browser storage exists. The server cannot make the same assumption. If the component participates in SSR, you need to think carefully about where that value should come from and when it should be read.

Likewise:

<p>{window.innerWidth}</p>

asks for browser-specific state during rendering.

Hydration forces us to confront a fundamental reality:

Server Environment
       ≠
Browser Environment

Code that crosses that boundary needs to be designed accordingly.

A Practical Example: Theme Preference

Suppose a user prefers dark mode. The browser has:

localStorage.setItem("theme", "dark");

But the server doesn’t have access to that browser storage. It renders:

<body class="light">

Then the browser loads JavaScript and discovers:

Theme = dark

The page switches:

Light
  │
  ▼
Dark

The user may see a flash of the wrong theme. This isn’t necessarily a hydration problem alone, but it demonstrates how server/client differences can become visible.

One solution might be storing the preference in a cookie the server can read.

Then:

Cookie
  │
  ├────► Server renders dark
  │
  └────► Client initializes dark

Both sides agree.

This illustrates a broader principle:

The closer server and client are to sharing the same initial truth, the smoother hydration becomes.

A Practical Example: Responsive Rendering

Suppose the server tries to render different markup for mobile and desktop.

if (window.innerWidth < 768) {
    return <MobileNavigation />;
}

return <DesktopNavigation />;

There’s an immediate problem. On the server, window doesn’t exist. You could guess based on request information, but that guess may differ from the browser’s actual environment.

A safer solution is often letting CSS handle purely visual responsive differences:

.desktop-nav {
    display: block;
}

.mobile-nav {
    display: none;
}

@media (max-width: 768px) {
    .desktop-nav {
        display: none;
    }

    .mobile-nav {
        display: block;
    }
}

The server can produce stable markup while the browser’s CSS handles presentation.

Hydration encourages developers to distinguish between:

Application state

and

Presentation state

Not every browser difference needs to become JavaScript logic.

When Hydration Is Worth the Cost

After discussing all these problems, hydration can sound like something we should avoid completely. That’s not the lesson.

Hydration provides an extremely useful combination:

Fast server-rendered content

        +

Rich client-side interaction

For many applications, that’s exactly what we want. Imagine an e-commerce product page.

Users benefit from seeing:

Product Name
Image
Price
Description
Reviews

as early as possible.

But they also need:

Add to Cart
Choose Variant
Save Product
Update Quantity
Interactive Gallery

Server rendering plus hydration can provide both.

The question isn’t:

Is hydration bad?

The better question is:

How much hydration does this page actually need?

When You May Not Need Hydration

Suppose you’re building a documentation page.

It contains:

Heading
Paragraphs
Code examples
Images
Links

Perhaps the only interaction is copying code. Do you really need a full client-side framework runtime for the entire page? Possibly not.

You might send static HTML and use a tiny amount of JavaScript for:

Copy Button
Search
Theme Toggle

Likewise, a marketing page may need only:

Mobile menu
Newsletter form
Analytics

The rest can remain HTML and CSS.

A powerful frontend optimization is sometimes simply:

Don’t make static content into a JavaScript application unless it needs to be one.

Hydration Strategies Compared

We can summarize the main ideas.

Full Hydration

Entire Page
    │
    ▼
Hydrate

Simple mental model, but potentially more client-side work.

Partial Hydration

Page
├── Static
├── Interactive ◄── Hydrate
├── Static
└── Interactive ◄── Hydrate

Only interactive regions hydrate.

Lazy Hydration

Interactive Component
        │
        ▼
Wait until needed
        │
        ▼
Hydrate

Hydration is delayed.

Selective Hydration

Several regions waiting
        │
        ▼
User interacts
        │
        ▼
Prioritize relevant region

Urgent parts can receive attention first.

Server-Only Components

Component
    │
    ▼
Server
    │
    ▼
Rendered output

No client component
runtime required

Instead of optimizing hydration, avoid needing it for that component. These strategies aren’t necessarily mutually exclusive. Modern frameworks can combine several of them.

The Bigger Trend: Ship Less JavaScript

For years, frontend development often moved in one direction:

More application logic
        │
        ▼
More JavaScript
        │
        ▼
More client rendering

The industry is increasingly reconsidering that default.

Modern architectures ask:

Does this code need to run
in the browser?

        │
   ┌────┴────┐
   │         │
  Yes        No
   │         │
   ▼         ▼
Client      Server

That doesn’t mean JavaScript is going away. Far from it. Rich interfaces still depend heavily on it. But we can become more intentional about which JavaScript users actually need to download and execute.

Hydration is central to that conversation.

How to Think About Hydration Performance

When profiling a server-rendered application, don’t look only at how quickly HTML arrives. Think about the whole lifecycle.

Request
   │
   ▼
Server Rendering
   │
   ▼
HTML Arrives
   │
   ▼
Content Visible
   │
   ▼
JavaScript Downloads
   │
   ▼
JavaScript Executes
   │
   ▼
Hydration
   │
   ▼
Interaction Ready

Ask:

How much JavaScript are we shipping?
How much of it is needed immediately?
Which components actually require client-side behavior?
Is hydration producing long tasks?
Can below-the-fold functionality wait?
Are server and client producing the same initial state?
Can static sections remain server-only?
Are we measuring interaction responsiveness, not just page visibility?

Those questions are much more useful than simply asking whether SSR is enabled.

Connecting Everything We’ve Learned

We’re now four articles into Beyond the UI, and the pieces are beginning to connect.

First, we learned how browsers create pixels:

HTML
 │
 ▼
DOM
 │
 ▼
Render Tree
 │
 ▼
Layout
 │
 ▼
Paint
 │
 ▼
Composite

Then we learned how DOM and style changes can trigger expensive rendering work:

Reflow
Repaint
Compositing

Then we explored how JavaScript competes for time on the main thread:

Tasks
Microtasks
Event Loop
Rendering

Then we moved rendering to the server:

CSR
SSR
SSG
Hybrid Rendering

And now hydration connects those worlds:

SERVER

Components
    │
    ▼
HTML

    │
    ▼

BROWSER

HTML becomes visible
    │
    ▼
JavaScript arrives
    │
    ▼
Hydration
    │
    ▼
Interactive application

Frontend performance isn’t one thing. It’s the result of all these systems interacting.

Bringing It All Together

Hydration exists because server-rendered HTML and client-side applications solve different parts of the user experience.

Server rendering can give us:

Content quickly
SEO-friendly HTML
Useful initial document

Client JavaScript gives us:

State
Events
Interactions
Dynamic updates
Rich application behavior

Hydration connects them.

Server-Rendered HTML
          │
          │
          ├──── Client JavaScript
          │
          ▼
       Hydration
          │
          ▼
Interactive Application

But that connection has a cost. JavaScript must be transferred, parsed, and executed. The framework must connect itself to the server-rendered DOM, and the server and client must agree on what that initial DOM should represent.

That’s why newer frontend architectures increasingly ask whether every part of a page needs hydration at all.

Sometimes the best hydration optimization is:

Hydrate later.

Sometimes it’s:

Hydrate only this component.

And sometimes it’s:

Don't hydrate this component.

Final Thoughts

Hydration is easy to miss because, when everything works properly, the user never sees it. A page arrives, content appears, buttons work, and the application feels alive. But between those moments, the browser may be doing substantial work.

Understanding hydration helps explain why a server-rendered website can still ship too much JavaScript, why a visible page can still feel unresponsive, why server/client differences produce strange warnings, and why modern frameworks are becoming increasingly interested in server-only components, islands, streaming, and selective hydration.

Most importantly, hydration teaches us another lesson that keeps appearing throughout this series:

Frontend performance isn’t about making one stage fast. It’s about reducing unnecessary work across the entire journey from server to interaction.

The server can generate HTML in 50 milliseconds. The browser can paint it immediately. But if the user then has to wait while megabytes of JavaScript are downloaded, parsed, executed, and hydrated, we’ve optimized only part of the experience.

The real goal is not simply:

How quickly can we render the page?

It’s:

How quickly can we give the user a page that is both useful and ready to respond?

What’s Next?

We’ve now seen how a server-rendered application becomes interactive. But once the application is alive, another problem quickly appears. Where should all of its data live?

A simple component might have a boolean:

const [open, setOpen] = useState(false);

Then another component needs the same information, another page needs user data, the URL represents filters, API responses need caching, and forms have their own state.

Before long, everything seems to be called “state” even though these values have completely different lifecycles and responsibilities.

So next in Beyond the UI:

State Management Explained: Why Frontend State Gets Complicated

We’ll explore local state, shared state, server state, URL state, form state, and derived state, and why the solution to frontend state management isn’t simply putting everything into one global store.

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.

DEV Community: Billy Okeyo

Re-Renders Explained: What Actually Happens When Frontend State Changes

React Rendering Is Not Browser Rendering

What Happens When State Changes?

The Render Phase

Reconciliation

The Commit Phase

Re-Rendering Does Not Mean DOM Mutation

Why Child Components Re-Render

Parent Re-Render Does Not Mean Everything Changed

When Re-Renders Actually Become Expensive

A Simple Example of Expensive Rendering

What useMemo Actually Does

Do Not Memoize Everything

React.memo

Why React.memo Sometimes Doesn’t Work

What useCallback Actually Does

useMemo vs useCallback

Object Identity Causes Similar Problems

Keys and Reconciliation

Why Array Index Keys Can Be Problematic

State Position Matters

Render Phase vs Effects

Why Side Effects During Render Are Dangerous

Strict Mode Can Make This More Visible

Re-Renders and Context

Global State and Selectors

Server State Can Trigger Re-Renders Too

Rendering Large Lists

Component Boundaries Matter

Should You Fear Re-Renders?

The Wrong Way to Optimize

Measure Before Optimizing

A Practical Example

Rendering vs Committing

Re-Renders and the Event Loop

Re-Renders and the Browser Rendering Pipeline

A Better Mental Model

Practical Rules for Re-Render Performance

Bringing It All Together

Final Thoughts

What’s Next?

State Management Explained: Why Frontend State Gets Complicated

What Is State?

A Small Application Doesn’t Need “State Management”

When State Needs to Be Shared

Prop Drilling Appears

Not All State Is Application State

1. Local UI State

2. Shared Client State

3. Server State

Server State Has Different Problems

Server State Shouldn’t Automatically Live in Your Global Store

4. URL State

Don’t Duplicate URL State

5. Form State

6. Derived State

The Synchronization Trap

Another Derived State Example

State Gets Complicated When We Duplicate Truth

Impossible States

Think in State Machines

State Ownership Matters

State Lifetime Matters Too

Persistence Is Not the Same as State Management

Context Is Not Automatically a State Manager

Why Global Stores Exist

Redux Isn’t the Answer to Every State Problem

A Better State Architecture

Example: Building a Product Search Page

Filter Drawer

Search and Filters

Products

Shopping Cart

Number of Products

Why State Libraries Sometimes Make Things Worse

Why State Libraries Sometimes Make Things Much Better

State and Re-Renders

State Has Identity

Immutable Updates

What `useMemo` Actually Does

`React.memo`

Why `React.memo` Sometimes Doesn’t Work

What `useCallback` Actually Does

`useMemo` vs `useCallback`