DEV Community: Tanu Priya

Virtual DOM vs Real DOM: Is the Virtual DOM Actually Faster?

Tanu Priya — Mon, 31 Aug 2026 02:32:19 +0000

You've probably heard this before:

"React is fast because it uses a Virtual DOM."

It sounds reasonable.

The browser's DOM is often described as expensive, React uses a Virtual DOM, and therefore it's tempting to conclude:

Virtual DOM
     ↓
Faster than the Real DOM

But that's not quite how it works.

The Virtual DOM is not inherently faster than the Real DOM.

In fact, if you know exactly which DOM element needs to change, a direct DOM update can sometimes be faster than going through React's rendering and reconciliation process.

So why does React use a Virtual DOM?

What problem is it actually solving?

And if the Virtual DOM isn't simply "a faster DOM," what makes it useful?

Let's build the right mental model from the ground up.

1. What Is the Real DOM?

DOM stands for Document Object Model.

When a browser parses HTML, it creates an in-memory representation of the document as a tree.

For example:

<div>
  <h1>Hello</h1>
  <button>Click me</button>
</div>

Conceptually, the structure looks like this:

div
├── h1
│   └── "Hello"
└── button
    └── "Click me"

This is the Real DOM.

It's the actual document structure that the browser works with when displaying your webpage.

JavaScript can modify it directly:

document.getElementById("title").textContent = "Hello, Nayan";

That statement changes the actual DOM node.

And this leads to an important point:

Direct DOM manipulation isn't inherently bad or slow.

If you know exactly what needs to change, a direct DOM update can be extremely efficient.

For example:

element.textContent = "Updated";

There is very little abstraction involved.

You already know:

What changed
     ↓
Which element changed
     ↓
Update that element

So the statement:

Real DOM = Slow

is simply too simplistic.

2. Why Does the DOM Have a Reputation for Being Slow?

The DOM itself isn't necessarily the problem.

The browser often has additional work to perform after DOM changes.

A simplified rendering pipeline looks like this:

DOM Change
    │
    ▼
Style Calculation
    │
    ▼
Layout
    │
    ▼
Paint
    │
    ▼
Compositing
    │
    ▼
Pixels on Screen

The amount of work depends heavily on what changed.

Changing the text of a small element might be relatively inexpensive.

Changing a property that affects the layout of a large part of the page can require substantially more work.

So when developers say:

"DOM operations are expensive."

what they usually mean is:

Frequent or poorly managed DOM changes can cause additional browser work.

The important distinction is that the cost isn't simply:

DOM API call = Expensive

Instead, it can be closer to:

DOM Change
     ↓
Browser determines what is affected
     ↓
Style
     ↓
Layout
     ↓
Paint
     ↓
Composite

The exact pipeline varies depending on the type of change.

And there's one thing we can't escape:

Eventually, the browser has to update the Real DOM and render the result.

3. So What Is the Virtual DOM?

The Virtual DOM is a JavaScript representation of UI structure.

Consider this React UI:

<div>
  <h1>Hello</h1>
  <button>Click me</button>
</div>

Conceptually, React can represent the UI as a tree:

Virtual UI Tree

div
├── h1
│   └── "Hello"
└── button
    └── "Click me"

But there is a crucial distinction:

The Virtual DOM is not the browser's actual DOM.

It's a representation of what the UI should look like.

When your application state changes, React can calculate another representation of the UI.

It then reconciles the previous and next representations to determine what work needs to be committed to the actual UI.

Conceptually:

Previous UI
     │
     ▼
New UI
     │
     ▼
Reconciliation
     │
     ▼
Determine necessary changes
     │
     ▼
Commit DOM updates

This process is commonly called reconciliation.

And this is where the Virtual DOM becomes useful.

4. The Biggest Myth: "The Virtual DOM Is Faster"

Let's look at a simple example.

Suppose we have:

<h1 id="count">0</h1>

And we know that the value needs to become 1.

With direct DOM manipulation:

document.getElementById("count").textContent = "1";

That's a very targeted operation.

The program already knows:

The value changed
       ↓
The <h1> changed
       ↓
Update the <h1>

There's no need to calculate an entire UI representation just to perform that specific update.

So in this situation:

A direct DOM update can be faster.

This is why the claim:

"The Virtual DOM is faster than the Real DOM."

is misleading.

The Virtual DOM isn't designed simply to make one known DOM update faster.

Its value becomes much clearer when UI complexity increases.

5. The Real Problem: Managing Complex UI State

Now imagine a real application.

Your dashboard might depend on:

User
Products
Cart
Notifications
Permissions
Filters
Search
Loading state
Authentication state

A single state change might affect several different parts of the UI.

For example:

function Dashboard({
  user,
  products,
  cart,
  notifications
}) {
  return (
    <div>
      {/* Complex UI */}
    </div>
  );
}

Now imagine managing this entire interface with manual DOM operations.

You may need to determine:

Which element changed?
        │
        ▼
Which DOM node depends on it?
        │
        ▼
Should an element be added?
        │
        ▼
Should another element be removed?
        │
        ▼
Did an attribute change?
        │
        ▼
Does an event handler need updating?
        │
        ▼
Which elements should remain untouched?

As applications grow, manually keeping the DOM synchronized with application state becomes increasingly difficult.

This is where React's declarative model becomes valuable.

6. Declarative UI Changes the Way We Think

With imperative DOM manipulation, you tell the browser how to change the UI.

For example:

const button = document.getElementById("button");
const message = document.getElementById("message");

if (isLoggedIn) {
  button.style.display = "block";
  message.textContent = "Welcome back!";
} else {
  button.style.display = "none";
  message.textContent = "Please log in";
}

You're describing the steps required to change the interface.

React allows you to describe the desired UI instead:

function App({ isLoggedIn }) {
  return (
    <>
      {isLoggedIn && (
        <button>Dashboard</button>
      )}

      <h1>
        {isLoggedIn
          ? "Welcome back!"
          : "Please log in"}
      </h1>
    </>
  );
}

The difference is important.

Imperative

How should I change the UI?

Declarative

What should the UI look like?

React handles the transition between those states.

This is one of the biggest reasons React is useful for building complex interfaces.

7. How React Uses the Virtual DOM

Let's use a simple counter.

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

  return (
    <>
      <h1>{count}</h1>

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

Initially, the UI can be thought of as:

Fragment
├── h1
│   └── 0
└── button
    └── "Increment"

Now the user clicks the button.

The state changes:

count = 0
    │
    ▼
count = 1

React calculates the next UI:

Previous UI          Next UI

h1 → 0               h1 → 1
button → Increment   button → Increment

The important difference is:

0 → 1

React can then commit the necessary update to the actual DOM.

Conceptually:

State Change
     │
     ▼
Calculate Next UI
     │
     ▼
Reconcile
     │
     ▼
Determine Changes
     │
     ▼
Commit DOM Updates
     │
     ▼
Browser Rendering

Notice something important:

React does not replace the Real DOM with the Virtual DOM.

The Virtual DOM is an abstraction used as part of React's UI update process.

The browser still ultimately renders the Real DOM.

8. But Doesn't Reconciliation Add Extra Work?

Yes.

And this is another reason the phrase:

"The Virtual DOM is always faster."

doesn't make sense.

React itself has work to perform.

Depending on the update, React may need to:

Run component functions
        │
        ▼
Create React elements
        │
        ▼
Reconcile the UI
        │
        ▼
Determine changes
        │
        ▼
Prepare the update
        │
        ▼
Commit changes

Then the browser performs its own rendering work:

React
  │
  ▼
DOM Updates
  │
  ▼
Browser
  │
  ├── Style
  ├── Layout
  ├── Paint
  └── Composite

So the Virtual DOM isn't a magic shortcut that eliminates rendering work.

It is an abstraction.

And abstractions have costs.

The question is whether the abstraction provides enough value to justify those costs.

For complex applications, it often does.

9. Can Direct DOM Manipulation Be Faster?

Absolutely.

Suppose you have:

element.textContent = "Updated";

If you already know exactly which element needs to change, that's a very direct operation.

React may instead involve a higher-level process:

State Update
     │
     ▼
Render
     │
     ▼
Reconciliation
     │
     ▼
Commit
     │
     ▼
DOM Update

So why not simply use direct DOM manipulation everywhere?

Because raw performance isn't the only thing we're optimizing.

We're also optimizing for:

Developer productivity
Predictability
Maintainability
Scalability
Correctness
Code organization

A tiny application might be perfectly manageable with direct DOM manipulation.

A large application is a different story.

10. The Trade-Off React Makes

Imagine manually managing a large application.

You would need to keep application state synchronized with DOM state:

Application State
       │
       ▼
Which elements depend on it?
       │
       ▼
What changed?
       │
       ▼
What needs updating?
       │
       ▼
What should remain?
       │
       ▼
What should be removed?

As the application becomes more complex, the number of relationships increases.

React introduces a higher-level model:

Application State
       │
       ▼
Describe the UI
       │
       ▼
React determines changes
       │
       ▼
DOM is updated

You're giving up some low-level control in exchange for a more predictable programming model.

That's the trade-off.

And for many applications, it's a worthwhile one.

11. A Better Comparison: Imperative vs Declarative

This is why the Virtual DOM discussion is often framed incorrectly.

We tend to compare:

Virtual DOM
     vs
Real DOM

But a more useful comparison is often:

Imperative UI
     vs
Declarative UI

With imperative code:

const status = document.getElementById("status");

status.textContent = "Logged in";
status.classList.add("active");

You're explicitly describing the operations.

With React:

function Status({ isLoggedIn }) {
  return (
    <p className={isLoggedIn ? "active" : ""}>
      {isLoggedIn ? "Logged in" : "Logged out"}
    </p>
  );
}

You're describing the desired result.

The conceptual difference is:

Imperative
    │
    ▼
Tell the UI how to change


Declarative
    │
    ▼
Describe what the UI should be

That's a much more useful way to understand React.

12. Is the Virtual DOM the Fastest Rendering Strategy?

No.

Different UI technologies use different approaches.

Some rely on a Virtual DOM.

Others use techniques such as:

Fine-grained reactivity
Signals
Compile-time optimizations
Direct targeted DOM updates

For example, if a framework knows that a particular piece of state affects exactly one DOM node, it may be able to update that node directly.

Conceptually:

State
  │
  ▼
Known dependency
  │
  ▼
Specific DOM node
  │
  ▼
Update

No large UI tree comparison is necessarily required.

This doesn't make the Virtual DOM "bad."

It simply means:

The Virtual DOM is one strategy for managing UI updates — not the only strategy and not automatically the fastest.

There is no single rendering strategy that wins every possible performance scenario.

13. React's Strength Is Bigger Than the Virtual DOM

Reducing React to:

"React is fast because of the Virtual DOM."

misses the bigger picture.

React's strength comes from a combination of ideas:

Declarative UI
      +
Component Architecture
      +
State-Driven Rendering
      +
Reconciliation
      +
Scheduling
      +
Reusable Abstractions
      +
Large Ecosystem

The Virtual DOM is one piece of that larger model.

It shouldn't be treated as a magical performance feature.

You can still build a slow React application.

For example:

Huge unnecessary renders
Heavy calculations
Large unoptimized lists
Expensive component trees
Poor state architecture
Large JavaScript bundles
Slow network requests
Unoptimized images

The Virtual DOM doesn't automatically solve these problems.

14. The Virtual DOM Doesn't Make Expensive JavaScript Disappear

Consider this component:

function ProductList({ products }) {
  const sortedProducts = products
    .filter((product) => product.inStock)
    .sort((a, b) => b.price - a.price);

  return (
    <>
      {sortedProducts.map((product) => (
        <ProductCard
          key={product.id}
          product={product}
        />
      ))}
    </>
  );
}

Imagine products contains thousands of items.

If this filtering and sorting happens repeatedly, you can still create a performance problem.

The Virtual DOM doesn't magically make those calculations free.

The flow is still:

Component Render
       │
       ▼
JavaScript Calculations
       │
       ▼
UI Reconciliation
       │
       ▼
DOM Updates
       │
       ▼
Browser Rendering

Every stage can potentially become a bottleneck.

That's why good React performance requires looking beyond the Virtual DOM.

15. What Should You Actually Optimize?

Instead of obsessing over the Virtual DOM, pay attention to the things that actually affect your application.

State Architecture

Where state lives matters.

Putting frequently changing state unnecessarily high in the component tree can cause more work than necessary.

Re-render Behavior

Understand what causes components to render.State updates, props, context, and parent renders can all influence rendering behavior.

Expensive Calculations

Heavy JavaScript work can block the main thread regardless of how efficiently DOM updates are handled.

Large Lists

Rendering thousands of DOM nodes is still expensive.

The Virtual DOM doesn't make a massive DOM free.

Network Performance

Slow API requests can make an application feel slow even if rendering is extremely efficient.

Images and Assets

Large images and unnecessary assets can have a significant effect on loading and runtime performance.

Bundle Size

Shipping unnecessary JavaScript increases the amount of work the browser has to download, parse, and execute.

Real User Experience

Most importantly:

Optimize based on measurable problems, not assumptions.

If a component renders three times, that doesn't automatically mean your application has a performance problem.

Measure first.

Then optimize the bottleneck.

16. The Right Mental Model

If there's one thing you remember from this article, don't remember:

"Virtual DOM is faster than Real DOM."

Instead, remember:

"The Virtual DOM is an abstraction that helps React manage UI changes declaratively."

The overall process is closer to:

Application State Changes
          │
          ▼
   React Calculates
      Next UI
          │
          ▼
    Reconciliation
          │
          ▼
  Necessary DOM Changes
          │
          ▼
    Browser Rendering

The Virtual DOM is part of that process.

It is not a replacement for the Real DOM.

It does not eliminate browser rendering work.

And it is not automatically faster than direct DOM manipulation.

17. So, Is the Virtual DOM Actually Faster?

Not by itself.

That's the important distinction.

If you know exactly which DOM node needs to change, a direct DOM update can be extremely efficient.The Virtual DOM introduces additional work because React needs to calculate and reconcile UI changes before committing the necessary updates.

So the value of the Virtual DOM isn't simply:

Virtual DOM
      ↓
Faster DOM

A better mental model is:

Virtual DOM
      │
      ▼
Representation of UI
      │
      ▼
Reconciliation
      │
      ▼
Determine Necessary Changes
      │
      ▼
Commit to Real DOM
      │
      ▼
Browser Renders UI

18. The One-Sentence Explanation

If someone asks you:

"Why does React use the Virtual DOM?"

you don't need to say:

"Because it's faster than the Real DOM."

A better answer is:

"React uses a Virtual DOM as part of a declarative rendering model that helps it calculate and manage changes to the UI."

And if someone says:

"But isn't the Virtual DOM faster than the Real DOM?"

You can say:

"Not necessarily. A direct DOM update can be faster when you already know exactly what needs to change. The Virtual DOM's real value is helping React manage complex, state-driven UI updates in a predictable way."

That's the mental model worth remembering.

Final Takeaway

The Virtual DOM isn't a faster version of the Real DOM.
It's an abstraction.Its purpose is not to make every DOM operation magically faster.

Its purpose is to help React manage complex, state-driven interfaces using a declarative programming model.The browser still needs the Real DOM.React still needs to do work.

And performance still depends on how your application is designed.

So instead of thinking:

Virtual DOM
     ≠
Automatically faster than Real DOM

think:

Application State
       │
       ▼
Declarative UI
       │
       ▼
Virtual UI Representation
       │
       ▼
Reconciliation
       │
       ▼
Necessary DOM Updates
       │
       ▼
Browser Rendering

That's a much more accurate — and much more useful — way to understand the Virtual DOM.

Why Does Your React App Re-render So Much?

Tanu Priya — Sun, 30 Aug 2026 07:19:31 +0000

You update one small piece of state:

setCount(count + 1);

And suddenly your console looks like this:

Header rendered
Sidebar rendered
ProductList rendered
ProductCard rendered
Footer rendered

Your first thought might be:

"Why did half of my React app render again? Isn't this bad for performance?"

Not necessarily.

One of the biggest misconceptions about React performance is that every re-render is a problem.

It isn't.

React components are designed to render when their inputs change. A render is simply part of how React determines what the UI should look like.

The real question is not:

"How do I stop React from re-rendering?"

It's:

"Is this re-render causing unnecessary expensive work?"

That distinction is the foundation of understanding React performance.

What Does a Re-render Actually Mean?

Consider this simple component:

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

  console.log("Counter rendered");

  return (
    <>
      <h1>{count}</h1>

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

When the button is clicked, count changes.

React then needs to calculate what the component should produce with the new state.

A simplified mental model is:

State changes
     ↓
Component renders
     ↓
Next UI is calculated
     ↓
React reconciles the result
     ↓
Necessary changes are committed

The important distinction is:

Re-render ≠ Complete DOM rebuild

A re-render means React performs rendering work again to determine the component's next output.

It does not mean React destroys the entire browser DOM and recreates it from scratch.

In fact, React can render a component and discover that little—or even nothing—needs to change in the actual DOM.

So:

A re-render is normal. Unnecessary expensive work is what you should care about.

What Causes a Component to Render?

Before optimizing a component, you need to understand why it rendered in the first place.

There are several common causes.

1. Its State Changes

This is the most obvious case.

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

When you call:

setCount(count + 1);

React receives a state update and schedules work to update the component.

The component needs to calculate its UI using the new state.

That's completely normal.

2. Its Parent Renders

This is where many developers get confused.

Consider:

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

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

      <Header />
    </>
  );
}

Now imagine:

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

  return <h1>My Website</h1>;
}

When count changes, App renders again.

As part of processing the updated tree, React may also render Header.

So you might see:

Header rendered

even though Header doesn't use count.

This often leads developers to think:

"React is unnecessarily rendering my entire application!"

But that's too simplistic.

If Header is tiny and its render is cheap, another render may have practically no meaningful performance impact.

The important question is not whether Header rendered.

It's:

How much work did that render actually do?

3. Its Props Change

Props are another source of updates.

function Profile({ name }) {
  return <h1>{name}</h1>;
}

Used like this:

function App() {
  const [name, setName] = useState("Nayan");

  return <Profile name={name} />;
}

When name changes, Profile receives different input and needs to calculate its new UI.

That's exactly what we expect.

New props
   ↓
New component input
   ↓
New render

Again, this isn't automatically a performance problem.

4. A Context Value Changes

Context can also cause components that consume that context to update.

For example:

const ThemeContext = createContext();

function ThemeProvider({ children }) {
  const [theme, setTheme] = useState("light");

  return (
    <ThemeContext.Provider value={theme}>
      {children}
    </ThemeContext.Provider>
  );
}

A component can consume it:

function Navbar() {
  const theme = useContext(ThemeContext);

  return <nav className={theme}>Navbar</nav>;
}

When the context value changes, components consuming that context can update.

This becomes especially important when one context contains many unrelated pieces of frequently changing state.

For example:

User
Theme
Notifications
Cart
Language

If everything lives inside one large context, a change to one part can cause more consumers to be affected than necessary.

Sometimes separating unrelated concerns into smaller contexts is a better design.

5. State Used by a Custom Hook Changes

Custom hooks don't render independently.

Consider:

function useWindowWidth() {
  const [width, setWidth] = useState(window.innerWidth);

  return width;
}

And:

function App() {
  const width = useWindowWidth();

  return <h1>{width}px</h1>;
}

If the hook's state changes, the component using that hook is updated.

A useful rule is:

Hooks don't render independently. The component using them renders.

This distinction becomes helpful when debugging applications with many custom hooks.

The Biggest Source of Unnecessary Work: State in the Wrong Place

Now we get to one of the most useful React performance ideas.

Consider this:

function App() {
  const [search, setSearch] = useState("");

  return (
    <>
      <SearchBox
        search={search}
        setSearch={setSearch}
      />

      <ExpensiveDashboard />
      <Sidebar />
      <Footer />
    </>
  );
}

Imagine the user types:

N
Na
Nay
Naya

Every keystroke changes search.

Because search lives in App, App updates on every keystroke.

That means React has to process the tree below that component repeatedly.

Now ask:

Does search actually need to live in App?

If only SearchBox needs that state, placing it closer to SearchBox can reduce the scope of the updates.

For example:

App
├── SearchBox
│     └── Search state
├── ExpensiveDashboard
├── Sidebar
└── Footer

Instead of:

App
├── Search state
├── SearchBox
├── ExpensiveDashboard
├── Sidebar
└── Footer

This idea is called state colocation.

And it is one of the most useful optimization techniques in React because you're improving the structure of the application rather than adding optimization APIs everywhere.

Before reaching for:

React.memo(...)

or:

useMemo(...)

or:

useCallback(...)

ask:

Can this state live closer to where it is actually needed?

Often, that's the better solution.

Why "Re-render" Doesn't Mean "DOM Update"

This distinction is worth making extremely clear.

Suppose React renders:

<h1>Welcome</h1>

and the next render produces:

<h1>Welcome</h1>

The component rendered.

But the resulting UI is effectively the same.

So React may have no meaningful DOM change to commit.

That's why these concepts should stay separate:

Render
   ↓
Reconciliation
   ↓
Commit
   ↓
DOM changes

A render can happen without a meaningful DOM update.

This is why seeing:

Component rendered

in the console is not enough evidence that something is wrong.

What Is Reconciliation?

During an update, React needs to determine how the new element tree relates to the previous one.

Imagine:

Previous UI

Count: 0

becoming:

Next UI

Count: 1

The surrounding structure may remain the same while the displayed value changes.

React's reconciliation process determines how the current tree should transition toward the next one.

You may have heard this explained as:

"React compares the old Virtual DOM with the new Virtual DOM."

That's a useful beginner-friendly explanation, but it's an oversimplification.

React has its own internal representations and reconciliation machinery. It isn't simply taking two snapshots of the browser DOM and comparing them.

For practical React development, the more useful mental model is:

React calculates the next UI and determines what work is required to transition the current tree toward it.

What Happens During the Commit?

After React finishes the necessary rendering and reconciliation work, it reaches the commit phase.

This is where React applies the required changes to the host environment.

In a browser, that means updating the DOM.

For our counter:

Count: 0

eventually becomes:

Count: 1

The key point is that React doesn't need to rebuild the entire DOM simply because a component rendered again.

It commits the changes that are actually required.

What About the Browser?

React isn't the final step.

After the DOM has been updated, the browser still needs to turn that state into pixels.

A simplified browser pipeline looks like:

DOM + CSS
   ↓
Style
   ↓
Layout
   ↓
Paint
   ↓
Composite
   ↓
Pixels

This is important because React performance and browser rendering performance aren't exactly the same thing.

You can have:

expensive React rendering
expensive DOM work
expensive layout
expensive painting

Understanding where the actual cost occurs is much more useful than simply counting renders.

Why Can Re-renders Be Expensive?

A re-render itself isn't necessarily expensive.

The work performed during that render might be.

Imagine a component that:

filters thousands of records
renders a huge list
performs complex calculations
renders a complicated chart
causes many expensive children to update

Now frequent renders may matter.

Compare:

Render
  ↓
Small component
  ↓
Cheap work
  ↓
Probably fine

with:

Render
  ↓
Heavy calculations
  ↓
Large list
  ↓
Expensive children
  ↓
Noticeable lag

That's the difference.

So don't optimize because you see the word:

rendered

in your console.

Optimize when there is unnecessary work that actually matters.

What About `React.memo`?

React.memo can prevent a child component from rendering when its props haven't changed, assuming the relevant comparison indicates that the props are equal.

For example:

const Profile = React.memo(function Profile({ name }) {
  console.log("Profile rendered");

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

Now:

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

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

      <Profile name="Nayan" />
    </>
  );
}

When count changes, App renders again.

But Profile still receives the same name.

Because it's memoized, React can potentially skip rendering Profile.

Conceptually:

Parent renders
      ↓
Child props unchanged
      ↓
Memoization can skip child render

But React.memo isn't something you should automatically add to every component.

It is most useful when:

the parent renders frequently
the child is relatively expensive
the child's props often remain unchanged
avoiding the render actually provides a measurable benefit

For a tiny component like:

function Label({ text }) {
  return <span>{text}</span>;
}

memoization may provide little practical benefit.

Don't use React.memo because a component can re-render. Use it when skipping that render is actually useful.

The Hidden Problem: New Object References

There is another reason memoization can sometimes fail to provide the expected benefit.

Consider:

const Profile = React.memo(function Profile({ user }) {
  return <h1>{user.name}</h1>;
});

And:

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

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

      <Profile user={{ name: "Nayan" }} />
    </>
  );
}

Every time App renders, this creates a new object:

{ name: "Nayan" }

Even though the contents are the same, the object itself is a new reference.

Conceptually:

Previous render → Object A
Next render     → Object B

Object A !== Object B

This matters because memoization compares props using shallow equality.

The same idea can apply to arrays and functions.

For example:

<Profile items={["React", "Next.js"]} />

or:

function App() {
  const handleClick = () => {
    console.log("Clicked");
  };

  return <Child onClick={handleClick} />;
}

A new function is created during each render.

But don't take this to mean:

"New objects and functions are bad."

They're not.

Creating a new object or function is perfectly normal JavaScript.

It only becomes relevant when reference stability is important for a specific optimization.

So What Is `useCallback` For?

useCallback can preserve a function reference between renders when its dependencies haven't changed.

For example:

const handleClick = useCallback(() => {
  console.log("Clicked");
}, []);

This can be useful when the callback is passed to a memoized child:

const Child = React.memo(function Child({ onClick }) {
  return <button onClick={onClick}>Click me</button>;
});

Without stable references, a newly created callback can cause the child's props to appear changed.

But that doesn't mean every function needs useCallback.

This:

const handleClick = () => {
  console.log("Clicked");
};

is perfectly fine in many situations.

The better rule is:

Use useCallback when a stable function reference enables a meaningful optimization.

Not simply because a function is created during rendering.

And What About `useMemo`?

useMemo can help avoid repeating an expensive calculation when its dependencies haven't changed.

For example:

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

This can make sense when the calculation is genuinely expensive.

It can also be useful when you need a stable value reference for another optimization.

But this:

const name = useMemo(() => "Nayan", []);

usually adds complexity without providing a meaningful benefit.

So again:

useMemo is an optimization tool, not a default requirement.

The Most Common React Performance Mistake

A developer opens the console and sees:

Dashboard rendered
Dashboard rendered
Dashboard rendered
Dashboard rendered

They immediately add:

React.memo
useMemo
useCallback

everywhere.

But they haven't answered the most important question:

Is the render actually causing a performance problem?

A small component can render many times and still be completely fine.

Meanwhile, a large component doing expensive work may be worth optimizing even if it renders less frequently.

So don't optimize based on the number of renders alone.

Optimize based on the cost of the work.

How to Investigate a Re-render

When you notice frequent rendering, work through these questions.

1. What caused it?

Was it:

state?
props?
context?
a parent update?
state used by a custom hook?
another update source?

First understand the trigger.

2. Does the component actually need that state?

If frequently changing state is stored high in the tree, ask whether it can move closer to the components that actually use it.

State colocation is often a cleaner solution than memoization.

3. Is the render expensive?

Look for:

large lists
heavy calculations
complex charts
expensive child components
slow interactions
visible UI lag

If the render is cheap, there may be nothing to fix.

4. Can the component structure be improved?

Sometimes the best optimization isn't an optimization API.

It might simply be:

Better component boundaries
Better state placement
Smaller update scope

Good architecture can prevent unnecessary work naturally.

5. Would memoization actually help?

Only after understanding the problem should you consider:

React.memo
useMemo
useCallback

And ideally, measure whether the change actually improved the situation.

The React Performance Mindset

This is the mindset I want you to remember.

When you see:

Component rendered

don't immediately think:

"Something is wrong."

Instead ask:

Why did it render?

Then:

What work did the render perform?

Then:

Is that work expensive enough to matter?

And finally:

What's the simplest way to reduce that work?

That might be:

Move state
     ↓
Split components
     ↓
Reduce unnecessary work
     ↓
Memoize when useful

Not:

Something rendered
     ↓
useMemo
     ↓
useCallback
     ↓
React.memo
     ↓
Everything is memoized

The Mental Model to Remember

React performance becomes much easier to understand when you separate these concepts:

State / Props / Context change
            ↓
      React renders
            ↓
   Next UI is calculated
            ↓
      Reconciliation
            ↓
          Commit
            ↓
      DOM is updated
            ↓
    Browser renders pixels

But don't confuse:

Re-render
    ≠
DOM update

or:

Parent re-render
    ≠
Performance problem

or:

Memoization
    ≠
Always necessary

Final Takeaway

React components are supposed to render.

A state change, a parent update, changed props, or a context update can cause rendering work.

That alone isn't a problem.

The real problem is unnecessary expensive work.

So when you see a component rendering more often than expected, don't immediately reach for React.memo, useMemo, or useCallback.

Instead:

Notice the render
      ↓
Understand what triggered it
      ↓
Measure the actual cost
      ↓
Improve component boundaries
      ↓
Keep state close to where it's needed
      ↓
Reduce unnecessary work
      ↓
Use memoization when it provides real value

The goal isn't to build an application where nothing re-renders.

The goal is to build an application where the work that happens during updates is appropriate for what actually changed.

So don't ask:

"How do I stop React from re-rendering?"

Ask:

"Is this render doing unnecessary work, and what's the simplest way to fix it?"

That small change in mindset is one of the most important steps toward understanding React performance.

And once you understand why a component rendered, what work it performed, and what actually reached the DOM, React optimization stops being a collection of tricks and starts becoming a reasoning problem.

What Really Happens When React State Changes?

Tanu Priya — Sat, 29 Aug 2026 08:59:12 +0000

You write:

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

Then the user clicks a button:

setCount(count + 1);

And suddenly:

Count: 0

becomes:

Count: 1

It looks simple.

But what actually happens between calling setCount() and seeing 1 on the screen?

React doesn't immediately find the <h1> element and change its text.

Instead, the state update starts a series of steps that eventually lead to the browser displaying the new UI.

The simplified mental model is:

State Update → Render → Reconciliation → Commit → Browser

Let's follow that process from beginning to end.

The Example

We'll use a simple counter:

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

  return (
    <div>
      <h1>Count: {count}</h1>

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

Initially, count is 0.

The user sees:

Count: 0

[ Increment ]

When the button is clicked, this runs:

setCount(count + 1);

So the state needs to change:

0 → 1

What happens next?

1. The State Update Is Scheduled

The first thing to understand is that setCount() is not a DOM manipulation command.

When you write:

setCount(1);

you're not telling the browser:

"Find the <h1> and change its text to 1."

You're telling React that the component's state has changed and that its rendered output may need to change.

That's a fundamentally different approach from imperative DOM manipulation.

For example, this is imperative:

document.querySelector("h1").textContent = "Count: 1";

Here, you're directly telling the browser what to change.

With React:

setCount(1);

you describe a state change, and React takes responsibility for determining the UI that should result from it.

2. React Renders the Component

After processing the state update, React needs to determine what the UI should look like with the new state.

Conceptually, our component now renders with:

count = 1

So this:

<h1>Count: {count}</h1>

produces:

<h1>Count: 1</h1>

This is what we mean when we say the component re-renders.

And here's one of the most important React concepts:

A re-render does not mean the entire DOM is recreated.

React is calculating the component's next UI output. It isn't throwing away the existing browser DOM and rebuilding everything from scratch.

So:

Re-render ≠ DOM rebuild

3. React Determines What Changed

Now React has a previous UI representation and a new one.

Previously:

Count: 0

Now:

Count: 1

The surrounding structure hasn't changed.

The <div> is still there.

The <h1> is still there.

The <button> is still there.

Only the displayed text has changed.

React's reconciliation process determines how the new element tree relates to the previous one and what work needs to be performed.

This is why reconciliation is often described as the process of figuring out what needs to change.

It's important not to think of this as React taking two snapshots of the browser DOM and comparing them.

React works with its own internal representations and reconciliation machinery to determine how the current tree should transition toward the next one.

4. React Commits the Changes

Once React has determined the work that needs to happen, it enters the commit phase.

This is where the required changes are applied to the host environment.

In a browser, that means updating the DOM.

For our counter, the result is effectively:

<h1>Count: 1</h1>

The important thing is that React doesn't need to recreate the entire DOM structure just because the state changed.

The existing DOM can be updated where necessary.

So we can think of the process as:

State Update
     ↓
Render
     ↓
Reconciliation
     ↓
Commit
     ↓
DOM Update

That's the core React mental model.

5. Then the Browser Has to Render It

React updating the DOM isn't quite the same thing as the user seeing pixels change.

The browser still has its own rendering work to perform.

A simplified version looks like:

DOM + CSS
   ↓
Style
   ↓
Layout
   ↓
Paint
   ↓
Composite
   ↓
Pixels

So there are actually two different systems involved.

React determines and applies the UI changes.

The browser takes the resulting DOM, styles, and other rendering information and turns them into pixels.

This distinction becomes especially useful when you start learning about frontend performance.

6. Render Doesn't Always Mean DOM Changes

Here's another important misconception.

Suppose a component renders again.

That doesn't necessarily mean the browser DOM changes.

Imagine React renders the same output as before:

Previous:

<h1>Hello</h1>

Next:

<h1>Hello</h1>

There may be no meaningful DOM mutation required.

So these are three different things:

Render
Reconciliation
DOM Update

A render can happen without producing a DOM change.

That's why saying:

"The component rendered, so React changed the DOM."

isn't necessarily correct.

7. Why Does a Component Re-render?

State updates are one reason.

But they're not the only reason a component can render.

For example, a component may render because:

its state changed
its parent rendered
a context value it uses changed
an external store triggered an update
another React-driven update occurred

This is why the statement:

"React only re-renders when state changes."

is too simplistic.

The more useful question is:

What caused this component to render, and what work did that render actually perform?

That question becomes very important when debugging performance.

8. What About the Virtual DOM?

You've probably heard:

"React uses a Virtual DOM."

And you've probably also heard:

"The Virtual DOM is a copy of the real DOM."

That's a useful beginner explanation, but it's an oversimplification.

A better mental model is:

React maintains in-memory representations of the UI and uses them as part of its rendering and reconciliation process.

When state changes, React calculates the next UI and determines how it should transition from the current tree.

The important idea isn't:

Virtual DOM = faster DOM

The more useful idea is:

You describe the UI.
React manages the transition.

This is a major part of what makes React declarative.

9. Declarative vs Imperative

Consider an imperative approach.

You might manually update the DOM:

title.textContent = user.name;

if (user.isOnline) {
  status.textContent = "Online";
  status.classList.add("active");
} else {
  status.textContent = "Offline";
  status.classList.remove("active");
}

Now your code needs to keep track of:

which element changed
what value it should have
which classes need to be added or removed
what happens when multiple pieces of state change

React lets you describe the desired UI instead:

<p>
  {isOnline ? "Online" : "Offline"}
</p>

You describe the UI for the current state.

React handles the transition from the previous result to the next one.

That's the declarative model.

10. What Happens With Multiple State Updates?

Consider:

setName("Nayan");
setAge(25);
setLoading(false);

It would be misleading to assume that React necessarily does this:

setName()
  ↓
render

setAge()
  ↓
render

setLoading()
  ↓
render

React can batch state updates so that multiple updates are processed together when appropriate.

Conceptually:

Multiple Updates
      ↓
React processes them
      ↓
Render
      ↓
Reconciliation
      ↓
Commit

This can reduce unnecessary work.

The exact behavior depends on the React version and execution context, but the important mental model is:

State setters are requests for React to update its rendered output, not direct DOM commands.

11. Does React Rebuild Everything?

No.

This is probably the most important misconception to eliminate.

Suppose a component contains:

return (
  <div>
    <h1>Welcome</h1>
    <p>{isOnline ? "Online" : "Offline"}</p>
    <button>Change Status</button>
  </div>
);

If isOnline changes, the component may render again.

But that doesn't mean React throws away:

<div>
<h1>
<button>

and creates completely new DOM elements for everything.

React's reconciliation process determines what changed and the commit phase applies the necessary updates.

So keep these distinctions in mind:

Component re-render
        ≠
Entire DOM recreated

Render
        ≠
DOM update

State update
        ≠
Direct DOM manipulation

These distinctions will save you from a lot of confusion later.

12. Why Can Re-renders Still Be Expensive?

If React doesn't rebuild the entire DOM, does that mean re-renders are free?

Definitely not.

A render can still perform a lot of JavaScript work.

Imagine a component that:

renders thousands of elements
performs expensive calculations
processes a large dataset
creates many objects
triggers many child renders

Even if the final DOM change is tiny, the work required to calculate that result might be expensive.

That's why React performance optimization focuses on questions such as:

Where should state live?
Which components actually need to render?
Are expensive calculations being repeated?
Are unnecessary child renders happening?
Would React.memo help?
Would useMemo or useCallback actually solve a real problem?
Should a large list be virtualized?

The goal isn't:

"Prevent every re-render."

The goal is:

Avoid unnecessary expensive work.

13. The Complete Journey

Let's return to our original example:

setCount(count + 1);

The user doesn't directly cause this:

setCount()
   ↓
DOM changes

A better mental model is:

User interaction
      ↓
State update
      ↓
React renders
      ↓
Reconciliation
      ↓
Commit
      ↓
Browser rendering
      ↓
Pixels on screen

For our counter, the visible result is simply:

Count: 0
     ↓
Count: 1

But underneath that tiny change, React and the browser perform several steps to produce the final result.

The Mental Model You Should Remember

When you see:

setCount(count + 1);

don't think:

"React changes the DOM."

Think:

"The state changed, so React needs to determine what the UI should look like now."

That leads to this mental model:

State changes
     ↓
React calculates the next UI
     ↓
React reconciles it
     ↓
React commits required changes
     ↓
Browser renders the result

And remember these three rules:

1. State updates are not DOM commands

setState ≠ DOM manipulation

2. Re-rendering does not mean rebuilding the entire DOM

Re-render ≠ DOM rebuild

3. Rendering does not necessarily mean the DOM changes

Render ≠ DOM update

Final Takeaway

React's core idea is surprisingly simple:

You describe what the UI should look like for a given state, and React manages the transition from the previous UI to the next one.

So the next time you write:

setCount(count + 1);

remember that you're not telling the browser:

"Change this text to 1."

You're changing the state that drives your UI.

React then determines the next rendered result, reconciles it with the previous one, commits the necessary changes, and the browser eventually turns that result into pixels.

JavaScript Event Loop: How Does JavaScript Handle Multiple Tasks?

Tanu Priya — Fri, 28 Aug 2026 08:53:33 +0000

JavaScript is often described as a single-threaded language.

At a high level, this means JavaScript executes JavaScript code on a single main thread, handling one piece of JavaScript execution at a time.

But modern applications constantly perform operations that take time:

API requests
Timers
Button clicks
User input
File operations
Animations

So an important question comes up:

If JavaScript executes one piece of code at a time, how can it handle asynchronous operations without freezing the application?

The answer is the Event Loop.

To understand it, we need to look at the different pieces involved:

             JavaScript Runtime

                  Call Stack
                      │
                      ▼
              JavaScript executes
                      │
          ┌───────────┴───────────┐
          │                       │
     Synchronous              Async work
       code                      │
                                  ▼
                              Host APIs
                                  │
                       ┌──────────┴──────────┐
                       ▼                     ▼
                Microtask Queue        Task Queue
                       │                     │
                       └──────────┬──────────┘
                                  ▼
                             Event Loop
                                  │
                                  ▼
                             Call Stack

Let's understand how this works.

1. The Call Stack

The Call Stack is where JavaScript keeps track of the functions it is currently executing.

Consider:

function first() {
  second();
}

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

first();

When first() is called, it goes onto the Call Stack.

Then first() calls second(), so second() is added on top.

Conceptually:

Call Stack

┌─────────────────┐
│    second()     │
├─────────────────┤
│     first()     │
└─────────────────┘

second() finishes first, so it is removed.

Then first() finishes.

This follows the LIFO principle:

Last In, First Out.

The important thing is that JavaScript cannot execute two pieces of JavaScript code simultaneously on the same main execution thread.

So if one task keeps the Call Stack busy for a long time, other JavaScript work has to wait.

2. What Happens With Asynchronous Work?

Now consider:

console.log("Start");

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

console.log("End");

You might initially expect:

Start
Timer finished
End

But the actual output is:

Start
End
Timer finished

Why doesn't JavaScript wait for two seconds?

Because the timer does not remain on the Call Stack.

The surrounding environment, such as the browser, provides APIs that can handle operations like timers and network requests.

A simplified flow looks like this:

Call Stack
    │
    │ setTimeout(...)
    ▼
Host / Browser APIs
    │
    │ wait for timer
    ▼
Timer becomes ready
    │
    ▼
Task Queue

Meanwhile, JavaScript is free to continue executing:

console.log("End");

That's why "End" appears before "Timer finished".

3. Host APIs Handle Asynchronous Operations

The browser provides many capabilities outside the JavaScript Call Stack.

Examples include:

Timers
DOM events
Network requests
Geolocation
Other browser functionality

For example:

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

The timer is registered with the host environment.

JavaScript doesn't sit there doing nothing for two seconds.

Instead:

JavaScript
     │
     │ Register timer
     ▼
Browser / Host
     │
     │ Timer runs
     ▼
Callback becomes ready
     │
     ▼
Task Queue

This is one of the key ideas behind asynchronous JavaScript:

JavaScript can delegate certain operations to its surrounding environment and continue executing other JavaScript code.

4. The Task Queue

When an asynchronous operation becomes ready, its callback may be scheduled as a task.

For example:

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

Once the timer is eligible to fire, its callback is placed into the appropriate task queue.

Conceptually:

Task Queue

┌──────────────────────────┐
│ console.log("Timeout")   │
└──────────────────────────┘

But being in the queue doesn't mean the callback executes immediately.

The Call Stack must be available, and the runtime's scheduling rules determine when the task gets a chance to run.

That's where the Event Loop comes in.

5. The Event Loop

The Event Loop coordinates when queued work gets an opportunity to execute.

A simplified mental model is:

        Call Stack
            │
            ▼
       Is it empty?
            │
       ┌────┴────┐
       │         │
      No        Yes
       │         │
       ▼         ▼
    Continue   Process
    execution  queued work

When JavaScript is busy executing code, queued callbacks have to wait.

When the current execution finishes, the runtime can process pending asynchronous work according to its scheduling rules.

This continuous coordination is what we call the Event Loop.

6. Microtasks: The Important Second Queue

Things become more interesting when Promises are involved.

Consider:

console.log("Start");

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

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

console.log("End");

The output is:

Start
End
Promise
Timeout

Why?

Because Promise reactions are scheduled as microtasks.

Examples of microtasks include:

Promise.then()
Promise.catch()
Promise.finally()
queueMicrotask()

So we can simplify the model into two categories:

Microtask Queue
    │
    ├── Promise callbacks
    └── queueMicrotask()

Task Queue
    │
    ├── Timers
    ├── User interaction tasks
    └── Other scheduled tasks

7. Why Does the Promise Run Before `setTimeout`?

Let's break down the previous example.

console.log("Start");

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

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

console.log("End");

Step 1: Synchronous code executes

First:

console.log("Start");

Output:

Start

Then the Promise reaction is scheduled as a microtask.

The timer is also registered.

Finally:

console.log("End");

runs.

Output so far:

Start
End

Now the current JavaScript execution has finished.

Step 2: Microtasks are processed

The Promise callback is waiting in the Microtask Queue:

Microtask Queue

[ Promise callback ]

The runtime processes pending microtasks before moving on to the next task.

So:

Promise

is printed.

Step 3: The timer task gets its turn

The timer callback is waiting as a task.

So:

Timeout

is printed.

Final output:

Start
End
Promise
Timeout

The key idea is:

After the current JavaScript execution finishes, pending microtasks are processed before the next task gets a chance to run.

8. A Classic Event Loop Question

Consider:

console.log("1");

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

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

console.log("4");

What will be printed?

Let's see why.

Synchronous code

console.log("1");
console.log("4");

produces:

1
4

Then the current execution finishes.

The Promise callback is a microtask:

Microtask Queue
    ↓
    3

The timer callback is a task:

Task Queue
    ↓
    2

Microtasks are processed first:

Then the timer task runs:

Therefore:

9. Does `setTimeout(..., 0)` Mean "Run Immediately"?

No.

This is one of the most common misconceptions about JavaScript timers.

Consider:

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

The 0 does not mean:

Run this callback immediately.

It means the timer has a minimum delay of approximately zero milliseconds before the callback becomes eligible to be scheduled.

It still has to wait for:

Current JavaScript execution
        ↓
Microtasks
        ↓
Scheduling opportunity
        ↓
Timer callback

For example:

console.log("Start");

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

console.log("End");

produces:

Start
End
Timeout

Even with a zero-millisecond delay.

10. What If JavaScript Is Busy?

Here's where the Event Loop becomes especially important.

Consider:

console.log("Start");

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

for (let i = 0; i < 10000000000; i++) {
  // Heavy computation
}

console.log("End");

The timer may become ready while the loop is running.

But its callback cannot interrupt the currently executing JavaScript.

The Call Stack is still busy.

Conceptually:

Call Stack
    │
    ▼
Heavy computation
    │
    │
    │  Timer becomes ready
    │
    ▼
Task Queue
    │
    │ WAIT
    │
    ▼
Call Stack becomes available
    │
    ▼
Timer callback executes

This is why a long-running JavaScript task can make a web page feel frozen.

Buttons may stop responding.

Animations can appear stuck.

Input can feel delayed.

Timers may execute later than expected.

11. JavaScript Isn't Doing Everything by Itself

A useful way to understand asynchronous JavaScript is to think of JavaScript as one worker coordinating with its environment.

For example:

             JavaScript
                  │
       ┌──────────┼──────────┐
       │          │          │
       ▼          ▼          ▼
     Timer      Network     Events
       │          │          │
       └──────────┼──────────┘
                  ▼
                Queues
                  │
                  ▼
              Event Loop
                  │
                  ▼
             Call Stack

JavaScript doesn't need to sit on the Call Stack waiting for every external operation to finish.

The host environment can handle the operation and later schedule the appropriate work for JavaScript.

This is what allows applications to remain responsive while waiting for things such as network responses or user interactions.

12. Why the Event Loop Matters

The Event Loop isn't just an interview question.

It directly affects real applications.

UI responsiveness

If the main thread is blocked by expensive JavaScript, the browser has less opportunity to process user interactions and update the page.

API calls

Network operations can take unpredictable amounts of time. JavaScript can continue executing other work instead of blocking the entire application while waiting.

Timers

A timer specifies when its callback becomes eligible, not an exact guarantee that it will execute at that exact moment.

Promises

Understanding microtasks explains why Promise callbacks often run before timer callbacks.

Performance

Large synchronous tasks can delay everything waiting for the main thread.

Understanding the Event Loop helps developers reason about all of these behaviors.

13. The Simplified Mental Model

You don't need to memorize every implementation detail.

Start with this model:

             JavaScript
                  │
                  ▼
             Call Stack
                  │
        ┌─────────┴─────────┐
        │                   │
   Sync execution       Async operation
                            │
                            ▼
                       Host APIs
                            │
                   ┌────────┴────────┐
                   ▼                 ▼
             Microtask Queue     Task Queue
                   │                 │
                   └────────┬────────┘
                            ▼
                       Event Loop
                            │
                            ▼
                       Call Stack

And remember the basic ordering:

Current JavaScript
        ↓
Microtasks
        ↓
Next task

That's the core idea.

14. The Restaurant Analogy

Here's another simple way to remember it.

Imagine a restaurant.

Call Stack
= Chef

Host APIs
= Kitchen staff handling things in the background

Microtask Queue
= High-priority orders

Task Queue
= Regular orders

Event Loop
= Manager deciding what the chef should handle next

The chef can prepare only one order at a time.

While something else is being prepared by the kitchen staff, the chef can work on another order.

When the chef becomes available, the manager coordinates which waiting work gets processed next.

The analogy isn't perfect, but it gives you the right intuition:

One execution thread doesn't mean the entire application has to stop whenever something takes time.

Final Mental Model

When you see asynchronous JavaScript, think:

1. JavaScript starts executing
             ↓
2. Synchronous code runs on the Call Stack
             ↓
3. Some operations are handled by the host environment
             ↓
4. Completed work is scheduled
             ↓
5. Current JavaScript execution finishes
             ↓
6. Microtasks are processed
             ↓
7. A task gets an opportunity to execute
             ↓
8. The cycle continues

Or, in one line:

Call Stack
    ↓
Host APIs
    ↓
Microtasks / Tasks
    ↓
Event Loop
    ↓
Call Stack

The most important thing to remember is that JavaScript's single-threaded execution model doesn't mean the application can perform only one kind of work at a time.

The JavaScript engine, host environment, queues, and Event Loop work together to coordinate asynchronous operations.

Once you understand that model, concepts like Promises, timers, API requests, event handlers, and UI responsiveness become much easier to reason about.

The Event Loop is essentially the mechanism that keeps asynchronous JavaScript moving without blocking every piece of work behind it.

How Does the Browser Turn Code Into Pixels?

Tanu Priya — Thu, 27 Aug 2026 02:56:47 +0000

When you build a website, you write code like this:

<h1>Welcome</h1>
<p>This is my website.</p>
<button>Get Started</button>

h1 {
  font-size: 48px;
  color: blue;
}

button.addEventListener("click", () => {
  console.log("Clicked!");
});

But your screen doesn't understand HTML.

It doesn't understand CSS.

And it doesn't understand JavaScript.

Your screen understands one thing:

Pixels.

So how does this:

HTML + CSS + JavaScript

become this?

A complete website on your screen

The browser has to process your code through a rendering pipeline:

HTML → DOM
CSS → CSSOM
       ↓
   Render Tree
       ↓
     Layout
       ↓
     Paint
       ↓
   Composite
       ↓
Pixels on Screen

Let's see what actually happens behind the scenes.

1. HTML Creates the Structure

Everything starts with HTML.

Suppose the browser receives:

<body>
  <h1>Hello World</h1>
  <p>Welcome to my website.</p>
</body>

The browser doesn't simply display this code directly.

Instead, it parses the HTML and creates a tree-like structure called the DOM.

DOM = Document Object Model

        BODY
       /    \
     H1      P
     |       |
  Hello    Welcome

The DOM represents the structure of the webpage.

It tells the browser:

What elements exist
How those elements are connected
What content they contain

At this point, the browser knows what the page contains.

But it still doesn't know how anything should look.

2. CSS Defines How Everything Should Look

Now the browser processes CSS.

h1 {
  color: blue;
  font-size: 48px;
}

p {
  color: gray;
}

The browser converts these styling rules into another structure called the CSSOM.

CSSOM = CSS Object Model

You can think of it like this:

DOM
"What exists on the page?"

CSSOM
"How should it look?"

The CSSOM contains styling information such as:

Colors
Fonts
Sizes
Margins
Padding
Borders
Positioning
Visibility

Now the browser has two important pieces of information:

DOM  → Structure
CSSOM → Styles

The next step is combining them.

3. DOM + CSSOM Create the Render Tree

The browser combines the DOM and CSSOM to create the Render Tree.

       DOM
        +
      CSSOM
        ↓
   Render Tree

The Render Tree represents the elements that actually need to be rendered on the screen.

Here's an interesting example:

<h1>Hello</h1>
<p>Welcome</p>

p {
  display: none;
}

The paragraph still exists in the DOM.

But because it isn't visible, it doesn't need to be rendered.

So:

DOM
= All elements in the document

Render Tree
= Elements that need to appear visually

Now the browser knows:

What should appear and how it should look.

But one major question still remains:

Where should everything go?

4. Layout Calculates the Exact Position of Everything

This stage is called Layout.

The browser calculates the exact geometry of every visible element.

For every element, it needs to determine things like:

Width
Height
Position
Spacing

Imagine a simple webpage:

+----------------------------------+
|              Header              |
+----------------------------------+
|                                  |
|           Main Content           |
|                                  |
+----------------------------------+
|              Footer              |
+----------------------------------+

The browser needs to calculate:

Where does the header start?
How wide is it?
How tall is it?

Where does the main content begin?
How much space does it take?

Where exactly should every piece of text appear?

In other words:

Render Tree
     ↓
Layout
     ↓
Exact size and position of every element

After this stage, the browser knows the complete geometry of the page.

Now it is finally ready to draw it.

5. Paint Turns the Page Into Visual Elements

The Paint phase is where the browser draws the visual parts of the page.

This includes:

Text
Colors
Backgrounds
Borders
Images
Shadows

For example:

.card {
  background: white;
  border: 1px solid #ddd;
  box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
}

Layout determines:

"The card goes here and has these dimensions."

Paint determines:

"Now draw its background, border and shadow."

You can think of it like this:

Layout
= Where does it go?

Paint
= What does it look like?

The browser now creates the visual output needed to display the page.

But modern browsers have one more important step.

6. Composite Combines Everything Together

A webpage is often split into multiple layers.

For example:

Background
    +
Content
    +
Images
    +
Fixed Header
    +
Animated Elements

During Compositing, the browser combines these layers to produce the final image on your screen.

Painted Layers
      ↓
   Composite
      ↓
Final Page

This is especially important for animations.

Some changes can be handled by moving or transforming existing layers instead of recalculating the entire page.

For example:

transform: translateX(100px);

That's why certain animations can be much smoother than others.

Where Does JavaScript Fit Into This Process?

JavaScript can change the webpage at any time.

For example:

document.querySelector("h1").textContent = "Welcome Back!";

Now the browser has to update what appears on the screen.

Or:

element.style.width = "500px";

Changing the width can affect the layout of other elements.

The browser may need to perform work again:

JavaScript changes something
        ↓
Style recalculation
        ↓
Layout
        ↓
Paint
        ↓
Composite

This is why JavaScript can have a major impact on frontend performance.

If your application repeatedly changes many elements, the browser may repeatedly perform expensive rendering work.

A Small Change Can Trigger Different Amounts of Work

This is one of the most important things to understand.

Imagine changing:

color: red;

The browser may only need to update the visual appearance.

But changing:

width: 500px;

can affect the layout.

And that may affect other elements around it.

So the browser may need to do more work:

Style
  ↓
Layout
  ↓
Paint
  ↓
Composite

This is why not every visual change has the same performance cost.

Understanding the rendering pipeline helps you understand why some updates are cheap and others are expensive.

The Complete Journey

Let's put everything together.

HTML
  ↓
Browser creates the DOM
  ↓
CSS
  ↓
Browser creates the CSSOM
  ↓
DOM + CSSOM
  ↓
Render Tree
  ↓
Layout
  ↓
Paint
  ↓
Composite
  ↓
Pixels on Your Screen

JavaScript can interact with this pipeline at different points by changing:

Content
Styles
Elements
Dimensions
Positions

And depending on what changes, the browser may need to update part of the rendering process again.

A Real-World Example

Suppose you create a simple card:

<div class="card">
  <h1>Hello</h1>
  <p>Welcome to my website.</p>
</div>

.card {
  width: 300px;
  padding: 20px;
  background: white;
  border-radius: 12px;
}

The browser roughly goes through this journey:

1. Read HTML
        ↓
2. Create DOM
        ↓
3. Read CSS
        ↓
4. Create CSSOM
        ↓
5. Create Render Tree
        ↓
6. Calculate Layout
   - Width: 300px
   - Padding: 20px
   - Text positions
   - Final height
        ↓
7. Paint
   - Background
   - Text
   - Border radius
        ↓
8. Composite
        ↓
9. Display Pixels on Screen

And this entire process happens incredibly fast.

Why Should Frontend Developers Understand This?

Because many performance problems are directly connected to this pipeline.

A slow website isn't always caused by "slow code."

Sometimes the browser is simply being forced to do too much work.

For example:

Too many style changes
        ↓
More rendering calculations

Frequent size or position changes
        ↓
More layout work

Complex visual effects
        ↓
More painting work

Heavy animations
        ↓
More compositing work

Once you understand this pipeline, you can start debugging performance more intelligently.

Instead of saying:

"The page feels slow."

You can ask:

Is JavaScript causing too many updates?
Is the browser recalculating layout too often?
Are too many elements being repainted?
Is this animation forcing unnecessary work?
Can I reduce what the browser needs to render?

That is where frontend development starts becoming much more interesting.

The Most Important Way to Remember It

Think of the browser as a factory.

HTML
↓
Creates the structure

CSS
↓
Adds the design

Render Tree
↓
Decides what should appear

Layout
↓
Calculates where everything goes

Paint
↓
Draws everything

Composite
↓
Combines everything together

Pixels
↓
What you finally see

Every button, image, card and animation on a website goes through some version of this journey before it reaches your screen.

Final Thought

When you look at a website, you see:

Text
Images
Buttons
Cards
Animations

But the browser sees:

Code
  ↓
Structure
  ↓
Styles
  ↓
Render Tree
  ↓
Layout
  ↓
Paint
  ↓
Composite
  ↓
Pixels

So the next time you open a website, remember:

Your browser isn't showing HTML and CSS.

It is constantly converting your code into millions of carefully calculated pixels.

What Actually Happens When You Open a Website?

Tanu Priya — Wed, 26 Aug 2026 05:08:19 +0000

You type:

https://example.com

Press Enter.

And within seconds, the website appears on your screen.

But have you ever wondered what actually happens between pressing Enter and seeing the webpage?

Behind this simple action, your browser performs an incredible chain of operations.

Let's follow the journey.

The Big Picture

You Enter a URL
        ↓
       DNS
        ↓
    IP Address
        ↓
Server Connection
        ↓
   HTTP Request
        ↓
      Server
        ↓
  HTTP Response
        ↓
 HTML + CSS + JS
        ↓
 Browser Rendering
        ↓
   Website on Screen

Let's break it down step by step.

1. You Enter a URL

Suppose you type:

https://example.com

This URL tells the browser what resource you want to access and where to look for it.

But there is one problem.

Computers don't really communicate using domain names like:

example.com

They communicate using IP addresses, such as:

93.184.216.34

So the browser first needs to answer one important question:

"Where is example.com located?"

That's where DNS comes in.

2. DNS Finds the Website

DNS stands for Domain Name System.

Think of it as the phonebook of the internet.

example.com
      ↓
     DNS
      ↓
93.184.216.34

The browser asks DNS:

"What is the IP address for example.com?"

DNS returns the address associated with that domain.

Now the browser knows where it needs to go. DNS lookups may also benefit from caching, so the browser does not necessarily need to repeat the full lookup every time.

3. The Browser Connects to the Server

Now that the browser knows the server's IP address, it establishes communication with the destination.

For an HTTPS website, the browser also needs to establish a secure connection before exchanging sensitive data.

Then the browser is ready to ask for the webpage.

4. The Browser Sends an HTTP Request

Your browser sends a request similar to:

GET / HTTP/1.1
Host: example.com

In simple terms, the browser is saying:

"Hey server, I want the homepage of this website."

This communication happens using HTTP or HTTPS, which defines how browsers and servers exchange requests and responses.

5. The Server Sends Back a Response

The server receives the request and sends a response.

That response may contain:

HTML
CSS
JavaScript
Images
Fonts
Other assets

The first response commonly gives the browser the initial HTML document.

And this is where the browser's real work begins.

6. HTML Becomes the DOM

The browser starts reading the HTML.

Imagine this:

<body>
  <h1>Hello World</h1>
  <p>Welcome to my website.</p>
</body>

The browser converts this HTML into a tree-like structure called the DOM (Document Object Model).

        HTML
          │
        BODY
       /    \
     H1      P
     │       │
 Hello    Welcome

The DOM becomes the browser's internal representation of the page structure.

But right now, the page still doesn't know how it should look.

That's CSS's job.

7. CSS Tells the Browser How Everything Should Look

The browser processes CSS rules such as:

h1 {
  color: blue;
  font-size: 40px;
}

CSS answers questions like:

What color should this element be?
How big should it be?
Where should it appear?
How much space should it take?

The browser creates a structure based on these styling rules, often described as the CSSOM.

HTML → DOM
CSS  → CSSOM

Then it combines the relevant information to prepare the page for rendering.

8. DOM + CSS = Render Tree

Now the browser combines:

DOM + CSSOM

to create the Render Tree.

The Render Tree focuses on the elements that need to be displayed.

       DOM
        +
      CSSOM
        ↓
   Render Tree

Now the browser knows:

What should appear on the screen and how it should look.

But it still needs to calculate where everything should go.

9. Layout: Calculating Positions

The browser calculates the:

Width
Height
Position
Spacing

of every visible element.

For example:

┌──────────────────────────────┐
│           Header             │
├──────────────────────────────┤
│                              │
│         Main Content         │
│                              │
├──────────────────────────────┤
│           Footer             │
└──────────────────────────────┘

This process is called Layout.

The browser now knows the exact geometry of the page.

10. Paint: Turning Everything Into Pixels

Now comes the step where the browser actually draws:

Text
Colors
Borders
Images
Shadows
Buttons

onto the screen.

Render Tree
     ↓
   Layout
     ↓
   Paint
     ↓
  Pixels 🎉

Finally...

You see the website!

The browser's rendering process broadly involves building the relevant document and style structures, calculating layout, and painting pixels to the screen.

But What About JavaScript?

JavaScript makes the website interactive.

It handles things like:

Button clicks
Form submissions
Dropdowns
Animations
API calls
Dynamic content

For example:

button.addEventListener("click", () => {
  alert("Hello!");
});

JavaScript can also modify the DOM and change what you see on the page. As the browser discovers scripts, stylesheets, images, and other resources, it may make additional requests and process them as part of loading the complete experience.

The Complete Journey

So, the next time you open a website, remember this:

You type a URL
        ↓
Browser finds the IP using DNS
        ↓
Secure connection is established
        ↓
Browser sends an HTTP request
        ↓
Server sends a response
        ↓
Browser receives HTML
        ↓
HTML → DOM
        ↓
CSS → CSSOM
        ↓
DOM + CSSOM → Render Tree
        ↓
Layout
        ↓
Paint
        ↓
JavaScript adds interactivity
        ↓
🎉 Website appears on your screen

Why Should Frontend Developers Understand This?

Because every frontend performance problem connects to this journey.

For example:

Slow DNS? → Navigation is delayed.
Slow server response? → HTML arrives late.
Large CSS files? → Rendering can be delayed.
Heavy JavaScript? → The page may become slow or unresponsive.
Large images? → More data needs to be downloaded and rendered.

Understanding this flow helps you understand why websites become slow — not just how to write frontend code.

Final Thought

Opening a website feels almost instant.

But in those few seconds, your browser has:

Found a server → communicated across the internet → requested resources → downloaded files → built the page structure → applied styles → calculated layouts → painted pixels → and executed JavaScript.

All from one simple action:

Pressing Enter.

The web might look simple from the outside.

*But underneath every page is a fascinating chain of engineering. *

Design a Scalable Chat Application Combine everything into one architecture

Tanu Priya — Tue, 25 Aug 2026 07:51:09 +0000

Building a chat application may seem simple at first.

A user sends a message, another user receives it, and the conversation continues.

But once your application grows from a few users to millions, the architecture becomes much more interesting.

You need to think about:

How do users connect in real time?
How are messages delivered?
Where are messages stored?
What happens when a server crashes?
How do you support millions of concurrent connections?
How do users receive messages when they're offline?
How do you monitor the entire system?

This is where all the concepts from system design come together.

In this article, we'll design a scalable chat application from requirements to a production-ready architecture.

Step 1: Understand the Requirements

Before choosing technologies, we need to understand what we're building.

Let's assume we're designing a WhatsApp- or Discord-like chat system.

Functional Requirements

Our application should support:

One-to-one messaging
Group chats
Real-time message delivery
Message history
Online/offline status
Read receipts
Typing indicators
Media messages
Push notifications

Non-Functional Requirements

The system should also provide:

Low latency
High availability
Scalability
Message durability
Fault tolerance
Observability

These requirements will guide our architecture.

Step 2: Estimate the Traffic

Let's assume:

10 Million Daily Active Users
1 Million Concurrent Users
100 Messages per User per Day

That gives us:

10M × 100 = 1 Billion Messages / Day

Average messages per second:

1,000,000,000 / 86,400

≈ 11,500 messages/second

But traffic is not evenly distributed.

Peak traffic could be several times higher.

Let's design for:

50,000+ messages/second

This tells us that a single server or database will eventually become a bottleneck.

Step 3: High-Level Architecture

A scalable chat system might look like this:

                         ┌──────────────┐
                         │    Users     │
                         └──────┬───────┘
                                │
                         WebSocket / HTTPS
                                │
                                ▼
                      ┌──────────────────┐
                      │  Load Balancer   │
                      └────────┬─────────┘
                               │
              ┌────────────────┼────────────────┐
              ▼                ▼                ▼
        ┌───────────┐    ┌───────────┐    ┌───────────┐
        │ Chat Node │    │ Chat Node │    │ Chat Node │
        └─────┬─────┘    └─────┬─────┘    └─────┬─────┘
              │                │                │
              └────────────────┼────────────────┘
                               ▼
                        ┌─────────────┐
                        │ Message Bus │
                        │ Queue/PubSub│
                        └──────┬──────┘
                               │
              ┌────────────────┼────────────────┐
              ▼                ▼                ▼
        Message Store      Presence         Notifications
              │             Service            Service
              ▼
         Chat Database

Each component has a specific responsibility.

This separation makes the system easier to scale independently.

Step 4: Real-Time Communication

Chat applications need a persistent connection between the client and server.

Using traditional HTTP polling would create unnecessary requests.

A better approach is:

Client
   │
   │ WebSocket Connection
   │
   ▼
Chat Server

Once connected, either side can send data instantly.

User A ─── Message ───→ Chat Server
                              │
                              ▼
                       User B receives it

WebSockets are useful for:

New messages
Typing indicators
Read receipts
Online presence
Live updates

Step 5: Scaling WebSocket Connections

A single chat server cannot maintain millions of connections.

Instead:

                      Load Balancer
                            │
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
          Chat Node 1    Chat Node 2    Chat Node 3

Each node manages a subset of active connections.

For example:

Node 1 → 100,000 Connections
Node 2 → 100,000 Connections
Node 3 → 100,000 Connections

As users grow:

More Users
     │
     ▼
Add More Chat Nodes

This provides horizontal scalability.

The load balancer can route new WebSocket connections to healthy nodes.

Step 6: Sending a Message

Let's follow a message from User A to User B.

User A
  │
  │ "Hello!"
  ▼
Chat Server

The server first validates:

Is the user authenticated?
Is the sender allowed in this conversation?
Is the message valid?

Then the message enters the processing flow.

Client
   │
   ▼
Chat Gateway
   │
   ▼
Authentication
   │
   ▼
Message Service

A message might look like:

{
  "messageId": "msg_123",
  "conversationId": "conv_456",
  "senderId": "user_A",
  "content": "Hello!",
  "timestamp": "2026-08-23T12:00:00Z"
}

The messageId is important for deduplication and idempotency.

Step 7: Store the Message First

A message should not be considered successfully sent until the system can reliably persist it.

User A
   │
   ▼
Message Service
   │
   ▼
Message Database
   │
   ▼
Message Stored ✅

After successful storage:

Message Service
       │
       ├──→ Deliver to recipient
       │
       ├──→ Update conversation
       │
       └──→ Trigger notifications

This improves durability.

If a chat server crashes after the message is stored, the message is not lost.

Step 8: Delivering Messages in Real Time

Now we need to find User B.

What if User B is connected to a different server?

User A
   │
   ▼
Chat Node 1
   │
   │ Message for User B
   ▼
        ?
   │
   ▼
Chat Node 3
   │
   ▼
User B

The system needs a way for chat servers to communicate.

This is where a message broker or Pub/Sub system can help.

                  Message Broker
                  /      |      \
                 ▼       ▼       ▼
              Node 1   Node 2   Node 3

The message can be published to the appropriate channel.

The node holding User B's connection delivers it.

User A
   │
   ▼
Node 1
   │
   ▼
Message Broker
   │
   ▼
Node 3
   │
   ▼
User B

Step 9: Managing User Presence

Presence tells us whether a user is:

Online
Offline
Away
Last seen recently

A fast in-memory store can manage this information.

user_123 → Chat Node 2
user_456 → Chat Node 3

When a user connects:

user_123 → ONLINE

When the connection closes:

user_123 → OFFLINE

A distributed presence store allows any chat server to find the user's active connection.

Step 10: What If the User Is Offline?

If User B is offline:

User A
   │
   ▼
Message Service
   │
   ├── Message Database ✅
   │
   └── User B Offline

The message remains stored.

The system can then send a push notification.

Notification Service
        │
        ▼
   Push Provider
        │
        ▼
     User B 📱

When User B reconnects:

User B
   │
   ▼
Chat Service
   │
   ▼
Fetch Unread Messages
   │
   ▼
Display Conversation

This ensures offline users don't lose messages.

Step 11: Supporting Group Chats

Group chats introduce another challenge.

Imagine a group with:

10,000 Members

If one user sends a message, how should it be delivered?

There are two common approaches.

Fan-Out on Write

When a message is sent:

Message
   │
   ├──→ User 1 Inbox
   ├──→ User 2 Inbox
   ├──→ User 3 Inbox
   └──→ Thousands More

Advantages

Fast reads
Easy message retrieval

Disadvantages

Expensive writes for large groups

Fan-Out on Read

Store the message once:

Group Message Store
        │
        ▼
Members read when needed

Advantages

Efficient writes
Better for very large groups

Disadvantages

More expensive reads

A real system may use a hybrid approach.

Step 12: Database Design

Chat applications generate massive amounts of data.

A simple message table might look like:

Messages
------------------------------------
message_id
conversation_id
sender_id
content
created_at
status

A useful query is:

SELECT *
FROM messages
WHERE conversation_id = ?
ORDER BY created_at DESC
LIMIT 50;

This suggests that messages should be efficiently organized around:

conversation_id + timestamp

This supports fast retrieval of recent messages.

Step 13: Database Partitioning and Sharding

As the number of messages grows, a single database may become too large.

We can partition messages:

Messages
   │
   ├── Partition 1
   ├── Partition 2
   └── Partition 3

Eventually, we may shard data across multiple database servers.

For example:

hash(conversation_id) % 4

Conversation A → Shard 1
Conversation B → Shard 2
Conversation C → Shard 3
Conversation D → Shard 4

Using conversation_id as a shard key keeps most messages from the same conversation together.

This makes message retrieval easier.

Step 14: Adding Caching

Some data is accessed frequently.

For example:

User profiles
Conversation metadata
Active conversations
Presence information

Instead of querying the database every time:

Application
     │
     ▼
    Cache
     │
     ├── Hit → Return Data ⚡
     │
     └── Miss → Database

Caching reduces:

Database load
Latency
Infrastructure cost

But the database remains the source of truth.

Step 15: Reliability and Fault Tolerance

Failures are inevitable.

Suppose one chat node crashes:

Chat Node 2 ❌

The load balancer should stop routing new connections to it.

Load Balancer
     │
     ├── Node 1 ✅
     ├── Node 2 ❌
     └── Node 3 ✅

Users connected to the failed node reconnect to healthy servers.

For critical components, we need redundancy.

                  Load Balancer
                         │
            ┌────────────┼────────────┐
            ▼            ▼            ▼
         Node 1        Node 2        Node 3

We also need:

Health checks
Timeouts
Retries
Circuit breakers
Database replicas
Automatic failover

The goal is to minimize the impact of individual failures.

Step 16: Handling Duplicate Messages

Distributed systems can deliver the same message more than once.

For example:

Message Sent
    │
Network Timeout
    │
Client Doesn't Know if Server Received It
    │
Client Retries

Without protection:

Hello!
Hello!

To prevent this, clients can generate a unique messageId.

messageId = msg_123

If the server receives the same message again:

msg_123 already processed

→ Ignore duplicate

This is called idempotency.

It is essential for reliable messaging.

Message Ordering

Users expect:

Hello
How are you?

Not:

How are you?
Hello

Ordering becomes difficult when multiple servers process messages.

A practical approach is to assign a sequence number within each conversation.

Conversation A

Message 1 → Sequence 101
Message 2 → Sequence 102
Message 3 → Sequence 103

Clients can then display messages in the correct order.

Step 17: Security and Authentication

Every connection must be authenticated.

A common flow:

User Login
    │
    ▼
Authentication Service
    │
    ▼
Access Token
    │
    ▼
WebSocket Connection

The server validates the token before allowing the user to connect.

The system should also verify:

Is the sender part of the conversation?
Does the user have permission to access this group?
Is the message within allowed limits?

Security should be enforced on the server—not trusted to the client.

Step 18: Observability

With multiple services and servers, debugging becomes difficult without visibility.

We need:

Logs

Message received
Message stored
Message delivered
Delivery failed

Metrics

Track:

Messages per second
Delivery latency
Active WebSocket connections
Error rate
Database latency
Queue size

Traces

Follow a message across the system:

Client
   │
   ▼
Chat Gateway
   │
   ▼
Message Service
   │
   ▼
Database
   │
   ▼
Message Broker
   │
   ▼
Recipient Chat Node

This helps identify bottlenecks quickly.

Putting Everything Together

Now we can combine everything into one architecture.

                              USERS
                                │
                    WebSocket / HTTPS
                                │
                                ▼
                        LOAD BALANCER
                                │
             ┌──────────────────┼──────────────────┐
             ▼                  ▼                  ▼
         CHAT NODE 1        CHAT NODE 2        CHAT NODE 3
             │                  │                  │
             └──────────────────┼──────────────────┘
                                │
                     ┌──────────┴──────────┐
                     ▼                     ▼
              PRESENCE SERVICE       MESSAGE SERVICE
                     │                     │
                     ▼                     ▼
               IN-MEMORY STORE      MESSAGE BROKER
                                           │
                          ┌────────────────┼───────────────┐
                          ▼                ▼               ▼
                     MESSAGE DB      NOTIFICATIONS      DELIVERY
                          │
                    ┌─────┴─────┐
                    ▼           ▼
                 REPLICA     REPLICA

Across the entire architecture:

                    OBSERVABILITY LAYER

        Logs ──────┐
        Metrics ───┼──→ Dashboards + Alerts
        Traces ────┘

And reliability mechanisms protect the system:

Redundancy
Retries
Timeouts
Circuit Breakers
Failover
Health Checks

Complete Message Flow

Let's follow one message end to end.

1. User A sends a message

User A → WebSocket → Chat Node

2. The server authenticates and validates it

Token Valid? ✅
Conversation Access? ✅
Message Valid? ✅

3. The message is stored

Message Service → Database

4. The message event is published

Database
   │
   ▼
Message Broker

5. Find User B

Presence Store
   │
   ▼
User B → Chat Node 3

6. Deliver in real time

Message Broker
   │
   ▼
Chat Node 3
   │
   ▼
User B 📱

7. If User B is offline

Message Stored ✅
        │
        ▼
Push Notification

8. Track the entire process

Logs + Metrics + Traces

This is the complete journey of a message.

How Does This System Scale?

As usage grows, individual components can scale independently.

More Connections?
→ Add Chat Nodes

More Messages?
→ Add Message Processing Workers

More Database Load?
→ Add Replicas / Partition / Shard

More Cache Load?
→ Expand Cache Cluster

More Notifications?
→ Add Notification Workers

This is one of the biggest advantages of separating responsibilities.

Scale the bottleneck, not the entire system.

Common Trade-Offs

There is no perfect architecture.

Every decision involves trade-offs.

Decision	Benefit	Trade-Off
WebSockets	Real-time communication	Connection management complexity
Message Broker	Decouples services	Additional infrastructure
Caching	Lower latency	Cache consistency
Sharding	Horizontal database scale	Operational complexity
Replication	Higher availability	Replication lag
Retries	Handles temporary failures	Can cause retry storms
Fan-out on write	Fast reads	Expensive for large groups
Fan-out on read	Efficient writes	Slower reads

Good system design is about understanding these trade-offs.

Final Takeaways

Designing a scalable chat application brings together nearly every major system design concept.

You start with requirements and traffic estimation.

Then you design for:

WebSockets for real-time communication
Load balancing for scalable connections
Message brokers for cross-server delivery
Databases for durable message storage
Caching for low-latency access
Partitioning and sharding for massive datasets
Redundancy and failover for reliability
Retries and idempotency for safe message delivery
Logs, metrics, and traces for observability

The final architecture is not about using every technology possible.

It's about combining the right components to build a system that is real-time, scalable, reliable, and easy to operate.

The complete system design mindset:

Requirements
     ↓
Estimate Scale
     ↓
Choose Architecture
     ↓
Identify Bottlenecks
     ↓
Add Caching
     ↓
Scale Components
     ↓
Design for Failure
     ↓
Add Observability
     ↓
Continuously Improve

*And that's how individual system design concepts come together to build a scalable real-world application. *

Observability: Understanding Your System Through Logs, Metrics, Traces & Monitoring

Tanu Priya — Mon, 24 Aug 2026 07:30:19 +0000

Modern distributed systems are complex.

A single user request might travel through multiple services, databases, caches, queues, and external APIs before a response is returned.

User
  │
  ▼
API Gateway
  │
  ▼
User Service ───→ Redis
  │
  ▼
Order Service
  │
  ▼
Payment Service
  │
  ▼
Database

Now imagine a user reports:

"The application is very slow."

Where is the problem?

Is it:

The API server?
The database?
Redis?
A slow microservice?
An external API?
A network issue?

Without visibility into the system, finding the answer can feel like searching in the dark.

This is where Observability becomes essential.

What Is Observability?

Observability is the ability to understand what is happening inside a system by analyzing the signals it produces.

In simple terms:

Observability helps you answer: "What is happening inside my system, and why?"

A system is observable when engineers can investigate unexpected behavior without needing to manually reproduce every problem.

For example:

Problem Detected
      │
      ▼
Check Metrics
      │
      ▼
Find Affected Service
      │
      ▼
Check Logs
      │
      ▼
Follow Request Trace
      │
      ▼
Find Root Cause

The foundation of observability is often built around three major signals:

Logs
Metrics
Traces

These are commonly called the three pillars of observability.

1. Logs — What Happened?

Logs are detailed records of events that occur inside a system.

For example:

2026-08-23 10:30:12 INFO User logged in
2026-08-23 10:30:15 INFO Payment request started
2026-08-23 10:30:16 ERROR Payment service timeout

Logs help answer questions like:

What happened?
When did it happen?
Which user or request was affected?
What error occurred?
Which service generated the error?

A useful log usually contains context.

For example:

{
  "timestamp": "2026-08-23T10:30:16Z",
  "level": "ERROR",
  "service": "payment-service",
  "request_id": "abc123",
  "message": "Payment provider timeout"
}

Instead of just seeing:

Error occurred

You now know:

When it happened
Which service failed
Which request was affected
What the failure was

This makes debugging significantly easier.

2. Metrics — How Is the System Performing?

Metrics are numerical measurements collected over time.

Examples include:

CPU usage
Memory usage
Request rate
Error rate
Response time
Database connections
Queue size

For example:

Requests per second: 12,000
Average latency: 120ms
Error rate: 0.4%
CPU usage: 68%

Metrics are useful because they help identify trends and anomalies.

Imagine this:

10:00 → 0.2% errors
10:05 → 0.3% errors
10:10 → 0.4% errors
10:15 → 8.7% errors 🚨

Something clearly changed.

Metrics help teams answer:

Is traffic increasing?
Is latency getting worse?
Is the error rate rising?
Is a server overloaded?

Unlike logs, metrics are especially useful for viewing the overall health of a system.

3. Traces — Where Did the Request Go?

Logs tell you what happened.

Metrics tell you how the system is performing.

But in a distributed system, you also need to know:

Where did this specific request travel?

This is where distributed tracing comes in.

Imagine a request:

User Request
     │
     ▼
API Gateway
     │ 20ms
     ▼
User Service
     │ 50ms
     ▼
Order Service
     │ 120ms
     ▼
Payment Service
     │ 2,500ms ⚠️
     ▼
Database

The total request is slow.

A trace quickly reveals that the payment service is responsible for most of the latency.

A distributed trace typically uses a Trace ID that follows the request across services.

Trace ID: xyz-789

API Gateway
     │
     ▼
User Service
     │
     ▼
Order Service
     │
     ▼
Payment Service

Each operation within the trace is called a span.

Trace
 ├── API Gateway Span
 ├── User Service Span
 ├── Order Service Span
 └── Payment Service Span

This makes it possible to follow one request across an entire distributed architecture.

The Three Pillars Together

Logs, metrics, and traces become far more powerful when used together.

Imagine an alert:

🚨 Payment Error Rate Increased

Step 1: Metrics

Metrics show:

Error Rate: 0.2% → 12%

You know there is a major issue.

Step 2: Traces

Traces show:

Most failed requests → Payment Provider

You now know where the failure is happening.

Step 3: Logs

Logs reveal:

Connection timeout after 5 seconds

Now you understand the root cause.

The debugging flow becomes:

Metrics
   ↓
Detect the problem
   ↓
Traces
   ↓
Locate the problem
   ↓
Logs
   ↓
Understand the problem

This combination dramatically reduces debugging time.

What Is Monitoring?

Observability and monitoring are related, but they are not exactly the same.

Monitoring focuses on tracking known signals and alerting you when something crosses a threshold.

For example:

CPU > 90% → Alert
Error Rate > 5% → Alert
Latency > 2 seconds → Alert

Monitoring answers:

"Is something wrong?"

Observability goes further and helps answer:

"Why is it wrong?"

A simple comparison:

Monitoring	Observability
Detects known problems	Helps investigate unknown problems
Uses dashboards and alerts	Uses multiple system signals
Answers "Is it failing?"	Answers "Why is it failing?"
Focuses on symptoms	Helps find root causes

You need both.

The Importance of Good Alerts

Not every metric should wake up an engineer at 3 AM.

Poor alerting can create:

100 Alerts
   ↓
Most Are Not Important
   ↓
Alert Fatigue
   ↓
Important Alert Gets Ignored

Good alerts should be:

Actionable
Meaningful
Relevant
Prioritized

Instead of alerting:

CPU usage is 80%

Consider alerting based on user impact:

Checkout error rate increased to 15%

The second alert provides a clearer reason to investigate.

The Four Golden Signals

A useful framework for monitoring production systems focuses on four important signals:

1. Latency

How long does a request take?

Average: 120ms
P95: 450ms
P99: 2.1s

Percentiles are important because averages can hide slow requests.

2. Traffic

How much demand is the system handling?

Requests per second: 15,000

A sudden spike may indicate:

Viral traffic
A marketing campaign
Bots
Abuse
A potential attack

3. Errors

How many requests are failing?

Error Rate: 0.3%

A sudden increase needs investigation.

4. Saturation

How close is the system to its capacity?

Examples:

CPU: 92%
Memory: 88%
Database Connections: 95%
Queue Capacity: 90%

High saturation means the system may soon become unavailable.

Correlation IDs: Connecting Everything

One of the most useful practices in observability is using a correlation ID.

When a request enters the system:

Request ID = req-12345

That ID travels with the request.

API Gateway → req-12345
User Service → req-12345
Order Service → req-12345
Payment Service → req-12345

Now you can search logs across multiple services and connect all events related to the same request.

This is especially valuable in microservice architectures.

Dashboards: Seeing the Health of Your System

A dashboard gives teams a quick view of important signals.

For example:

┌──────────────────────────────────┐
│ System Health                    │
├──────────────────────────────────┤
│ Requests/sec        12,400       │
│ Error Rate          0.4%         │
│ P95 Latency         320ms        │
│ CPU Usage           65%          │
│ Database Health     Healthy ✅    │
└──────────────────────────────────┘

A good dashboard should answer:

"Is my system healthy right now?"

Different dashboards may exist for:

Infrastructure
APIs
Databases
Business metrics
Individual services

Observability in Microservices

Observability becomes even more important when an application uses many services.

Consider:

                API Gateway
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
   User Service   Order Service  Search Service
        │            │
        ▼            ▼
   Database      Payment Service

A single request may involve multiple services.

Without distributed tracing and structured logs, debugging becomes extremely difficult.

With observability:

Request
   │
   ▼
Trace ID
   │
   ├── API Gateway
   ├── User Service
   ├── Order Service
   ├── Payment Service
   └── Database

You can understand the complete request journey.

What Makes a System Observable?

A strong observability strategy usually includes:

Structured Logging

Instead of:

Something failed

Use:

{
  "level": "ERROR",
  "service": "order-service",
  "request_id": "abc123",
  "error": "database_timeout"
}

Meaningful Metrics

Track metrics that matter:

Request latency
Error rate
Throughput
Resource utilization
Queue depth

Avoid collecting thousands of metrics that nobody uses.

Distributed Tracing

Propagate trace context across:

Services
Queues
Background jobs
External calls

This makes end-to-end debugging possible.

Centralized Visibility

Instead of logging into multiple servers:

Server 1 Logs
Server 2 Logs
Server 3 Logs
Server 4 Logs

Centralize your signals:

Logs ────┐
Metrics ─┼──→ Observability Platform
Traces ──┘

Now teams have one place to investigate incidents.

Common Observability Mistakes

1. Logging Too Much

More logs don't automatically mean better observability.

Excessive logs can create:

Higher storage costs
Noise
Slower investigations

Log useful information, not everything.

2. Logging Too Little

This is equally dangerous.

If an incident occurs and the logs only say:

Error

Finding the root cause becomes difficult.

Include meaningful context.

3. Monitoring Only Infrastructure

Your servers may look healthy while users are experiencing errors.

For example:

CPU: 30% ✅
Memory: 45% ✅

Checkout Success Rate: 40% ❌

Always monitor user-facing and business-critical metrics too.

4. Too Many Alerts

If everything creates an alert, nothing feels important.

Prioritize alerts based on real impact.

5. Missing Trace Context

If every service creates a completely separate trace, following a request becomes impossible.

Always propagate the trace and correlation context.

A Simple Observability Architecture

A typical architecture may look like this:

                    Application
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
      Logs            Metrics           Traces
        │                │                │
        └────────────────┼────────────────┘
                         ▼
              Observability Platform
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
    Dashboards         Alerts        Investigation

This gives teams visibility into both:

Current system health
The root cause of problems

Final Thoughts

You cannot reliably operate what you cannot understand.

As systems become larger and more distributed, observability becomes a core part of system design—not something added only after production issues begin.

Logs tell you what happened.

Metrics tell you how the system is performing.

Traces tell you where a request traveled.

Monitoring tells you when something needs attention.

Together, they help transform production incidents from confusing mysteries into problems that can be detected, investigated, and resolved faster.

Monitoring tells you that something is wrong. Observability helps you understand why.

Key Takeaways

Observability helps you understand what is happening inside a system.
The three core signals are logs, metrics, and traces.
Logs provide detailed event information.
Metrics reveal trends and overall system health.
Traces follow requests across distributed services.
Monitoring detects known problems and triggers alerts.
Good alerts should focus on meaningful user impact.
Use structured logs and correlation IDs for easier debugging.
Track latency, traffic, errors, and saturation.
Build observability into your system from the beginning.

*If reliability keeps your system running, observability helps you understand what happens when it doesn't. *

Reliability & Fault Tolerance: Designing Systems That Survive Failures

Tanu Priya — Sun, 23 Aug 2026 11:00:30 +0000

Modern applications are expected to be available almost all the time.

Users don't care if a server crashes, a database becomes unavailable, or a network connection fails—they simply expect the application to work. But in distributed systems, failures are not rare exceptions.

Failures are inevitable.

Servers crash. Networks fail. Databases become unavailable. Deployments go wrong. External APIs time out.

The goal of good system design is not to build a system where failures never happen.

The goal is to build a system that continues working even when failures happen.

This is where Reliability and Fault Tolerance become essential.

What Is Reliability?

Reliability is the ability of a system to perform its intended function correctly and consistently over time.

A reliable system should:

Return correct results
Handle expected traffic
Recover from temporary failures
Minimize downtime
Avoid data loss

For example, if an application promises 99.9% availability:

Total Time: 30 Days

Allowed Downtime ≈ 43 Minutes

Higher availability means less acceptable downtime.

Availability	Approx. Downtime per Month
99%	7 hours 18 minutes
99.9%	43 minutes
99.99%	4 minutes
99.999%	26 seconds

But achieving higher reliability also increases infrastructure complexity and cost.

What Is Fault Tolerance?

Fault tolerance is the ability of a system to continue operating even when one or more components fail.

Imagine a simple architecture:

Users
   │
   ▼
Application Server
   │
   ▼
Database

What happens if the application server crashes?

Application Server 

→ Entire application becomes unavailable

This architecture has a single point of failure.

A fault-tolerant system introduces redundancy:

                    Load Balancer
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
         Server 1               Server 2
             │                     │
             └──────────┬──────────┘
                        ▼
                     Database

If Server 1 fails:

Server 1 

Traffic → Server 2

The system continues serving users.

That is fault tolerance.

Types of Failures in Distributed Systems

Before designing for reliability, we need to understand what can fail.

1. Server Failures

A server can crash because of:

Hardware issues
Memory exhaustion
Application bugs
CPU overload
Operating system failures

Example:

Server 1 
Server 2 
Server 3

The system should detect the failure and redirect traffic.

2. Network Failures

Networks can experience:

Packet loss
High latency
Connection failures
DNS issues
Network partitions

A service might appear unavailable even though it is still running.

Service A ──── ❌ ──── Service B
        Network Failure

This is why distributed systems must carefully handle timeouts and retries.

3. Database Failures

Databases can fail due to:

Hardware crashes
Storage issues
Connection limits
Overloaded queries
Software bugs

A single database creates a major risk:

Application
     │
     ▼
Database

Even if every application server is running, the application may still be unavailable.

4. Dependency Failures

Modern applications often depend on external services.

For example:

Application
     │
     ├── Payment Service
     ├── Email Service
     ├── Authentication Service
     └── Analytics Service

If one dependency fails, your application should not always fail completely.

For example, an analytics failure should not prevent a user from completing a payment.

Redundancy: Don't Depend on One Component

One of the most important principles of fault tolerance is:

Avoid single points of failure.

Redundancy means having multiple components capable of performing the same function.

For example:

                  Load Balancer
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Server 1      Server 2      Server 3

If one server fails:

Server 1 
Server 2 
Server 3

The remaining servers continue handling requests.

Redundancy can exist at multiple levels:

Application servers
Databases
Load balancers
Data centers
Network connections

Database Replication

Databases are critical, so they often use replication.

A common architecture looks like this:

                 Application
                      │
              ┌───────┴───────┐
              ▼               ▼
           Primary         Replica
          Database        Database

The primary database handles writes:

Write Request
     │
     ▼
Primary Database

The data is then replicated to other databases:

Primary
   │
   ├────→ Replica 1
   │
   └────→ Replica 2

If the primary database fails, one replica may become the new primary.

This process is called failover.

Failover: Switching When Something Fails

Failover is the process of automatically switching traffic or operations from a failed component to a healthy backup.

Example:

        Before Failure

Application
     │
     ▼
Primary Server ✅

After failure:

Primary Server ❌
        │
        ▼
Backup Server Becomes Active ✅

The same concept can be used for:

Application servers
Databases
Network infrastructure
Data centers

A good failover mechanism should be:

Fast
Automatic
Reliable
Regularly tested

Because a backup system that has never been tested may fail exactly when you need it most.

Retries: Handling Temporary Failures

Not every failure is permanent.

Sometimes a request fails because of:

Temporary network issues
Short service overload
Brief database unavailability

In these cases, retrying the request can help.

Example:

Request ❌
   │
Retry 1 ❌
   │
Retry 2 ❌
   │
Retry 3 ✅

However, retries must be implemented carefully.

A naive retry strategy can make an outage worse.

Imagine 1 million failed requests immediately retrying:

1M Requests
    │
    ▼
Service Overloaded ❌
    │
    ▼
1M Immediate Retries
    │
    ▼
Even More Overload 💥

This is known as a retry storm.

Exponential Backoff

Instead of retrying immediately, systems often use exponential backoff.

Example:

Retry 1 → Wait 1 second
Retry 2 → Wait 2 seconds
Retry 3 → Wait 4 seconds
Retry 4 → Wait 8 seconds

This gives the failing service time to recover.

A more realistic approach also adds jitter, which introduces a small random delay.

Retry Delay = Exponential Backoff + Random Jitter

This prevents millions of clients from retrying at exactly the same time.

Timeouts: Don't Wait Forever

Every external call should have a reasonable timeout.

Bad design:

Application → Waiting forever...

Better design:

Application
     │
     ▼
Call External Service
     │
     ├── Response within 3 seconds → Continue
     │
     └── No response → Timeout ❌

Without timeouts, requests can remain stuck and consume valuable resources.

Timeouts help the system fail fast and recover gracefully.

Circuit Breakers

A circuit breaker prevents an application from repeatedly calling a service that is already failing.

Imagine this:

Application → Payment Service ❌
Application → Payment Service ❌
Application → Payment Service ❌
Application → Payment Service ❌

Instead, after repeated failures:

Circuit Breaker → OPEN 🔴

The application temporarily stops sending requests to the failing service.

Application
     │
     ▼
Circuit Breaker OPEN
     │
     └── Return fallback response

After some time, the system can test whether the dependency has recovered.

Typical circuit breaker states:

CLOSED → OPEN → HALF-OPEN → CLOSED

This prevents a failing dependency from causing a cascading failure across the entire system.

Graceful Degradation

A reliable system doesn't always need to provide every feature during a failure.

Instead, it can continue providing the most important functionality.

For example:

Normal Mode
├── Recommendations
├── Search
├── Payments
├── Notifications
└── Analytics

If the recommendation service fails:

Degraded Mode
├── Recommendations ❌ Temporarily Disabled
├── Search ✅
├── Payments ✅
├── Notifications ✅
└── Analytics ✅

The system is not perfect, but users can still perform critical actions.

This is called graceful degradation.

Health Checks

How does a load balancer know whether a server is healthy?

Using health checks.

For example:

GET /health

A healthy server might return:

{
  "status": "healthy"
}

The load balancer periodically checks each server:

Load Balancer
     │
     ├── Server 1 → Healthy ✅
     ├── Server 2 → Healthy ✅
     └── Server 3 → Unhealthy ❌

Traffic is automatically removed from unhealthy servers.

Health checks are especially important in distributed environments with multiple instances.

Monitoring: You Can't Fix What You Can't See

Reliability also depends on detecting problems quickly.

Important metrics include:

Error rate
Response time
CPU usage
Memory usage
Database latency
Request throughput
Failed requests

A monitoring system might detect:

Normal Error Rate: 0.2%

Current Error Rate: 15% 🚨

An alert can then notify engineers before the issue becomes a major outage.

Monitoring turns failures from:

"Users are complaining that the app is down."

into:

"We detected increasing errors and are investigating the problem."

Avoiding Cascading Failures

A cascading failure happens when one failure causes failures in other parts of the system.

Example:

Database Slows Down
       │
       ▼
Application Requests Wait
       │
       ▼
Threads Become Exhausted
       │
       ▼
Application Becomes Unresponsive
       │
       ▼
Entire System Fails 💥

To prevent this, systems use techniques such as:

Timeouts
Circuit breakers
Rate limiting
Queues
Bulkheads
Load shedding

The goal is to isolate failures instead of allowing them to spread.

The Bulkhead Pattern

A ship uses bulkheads to isolate flooded sections so the entire ship doesn't sink.

The same idea can be used in software.

Instead of sharing all resources:

One Shared Resource Pool

You isolate resources:

Payment Resources
Recommendation Resources
Search Resources
Notification Resources

If the recommendation service consumes all its resources, it doesn't necessarily affect payments or search.

This improves fault isolation.

A Reliable System Architecture

A highly reliable architecture might look like this:

                     Users
                       │
                       ▼
                  Load Balancer
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       App 1         App 2         App 3
          │            │            │
          └────────────┼────────────┘
                       ▼
                Primary Database
                       │
              ┌────────┴────────┐
              ▼                 ▼
          Replica 1         Replica 2

Additional systems may include:

Cache
Queue
Monitoring
Alerting
Backup Storage
Disaster Recovery

Each component contributes to the overall reliability of the system.

Reliability vs Fault Tolerance

These concepts are related but not exactly the same.

Reliability	Fault Tolerance
Focuses on consistent operation	Focuses on surviving failures
Reduces the chance of failure	Reduces the impact of failure
Includes monitoring and testing	Includes redundancy and failover
Measures how dependable a system is	Measures how well a system handles faults

A highly reliable system should ideally also be fault tolerant.

When Designing for Reliability, Ask These Questions

Whenever you design a system, ask:

What happens if this server crashes?

What happens if the database becomes unavailable?

What happens if a request times out?

What happens if an external API fails?

Can the system retry safely?

Is there a backup?

How does the system detect failures?

Can traffic automatically move to a healthy server?

Can one failing service bring down the entire system?

These questions often reveal weaknesses in a system before they become real outages.

Final Thoughts

Failures are a normal part of distributed systems.

You cannot completely prevent servers, networks, databases, or external services from failing. But you can design systems that expect failure and recover from it gracefully.

The core building blocks of reliable systems include:

Retries for temporary failures
Timeouts to prevent requests from hanging
Redundancy to remove single points of failure
Failover to switch to healthy components
Circuit breakers to prevent cascading failures
Monitoring to detect problems early
Health checks to identify unhealthy services
Graceful degradation to keep critical features running

The biggest mindset shift in system design is simple:

Don't ask, "Will this component fail?" Ask, "When it fails, what happens next?"

That is the foundation of Reliability and Fault Tolerance.

Key Takeaways

Failures are inevitable in distributed systems.
Reliability focuses on consistent, dependable operation.
Fault tolerance helps systems continue working during failures.
Redundancy removes single points of failure.
Retries should use exponential backoff and jitter.
Timeouts prevent requests from waiting indefinitely.
Failover redirects traffic to healthy components.
Circuit breakers prevent failing dependencies from causing larger outages.
Monitoring and health checks help detect failures quickly.
Design systems assuming that something will eventually fail.

*A scalable system handles growth. A reliable system survives failure. The best systems do both. *

Database Partitioning & Sharding: How to Distribute Massive Datasets

Tanu Priya — Sat, 22 Aug 2026 07:18:47 +0000

As an application grows, its database grows with it.

A small application might start with a few thousand users and a single database server. But what happens when that application reaches millions of users, processes thousands of requests per second, and stores terabytes or even petabytes of data?

At that point, simply buying a more powerful database server is not always enough.

This is where database partitioning and sharding come in.

In this article, we'll understand what they are, why they matter, how they work, and when you should use them.

The Problem: One Database Can Only Scale So Far

Imagine a social media application with:

100 million users
Billions of posts
Millions of requests per second
Terabytes of new data every day

Initially, you might have a single database:

              Application
                   │
                   ▼
            ┌─────────────┐
            │  Database   │
            │   Server    │
            └─────────────┘

As traffic grows, this server can become a bottleneck.

You may face:

Slow queries
High CPU usage
Memory limitations
Storage limitations
Increased latency
Database outages affecting the entire application

The obvious solution might seem simple:

Buy a bigger server.

This approach is called vertical scaling.

Small Server
     ↓
Bigger Server
     ↓
Even Bigger Server

But vertical scaling has limits.

You cannot infinitely keep upgrading a single machine.

Eventually, you need to distribute the data across multiple machines.

This is where partitioning and sharding become important.

What Is Database Partitioning?

Database partitioning means splitting a large dataset into smaller pieces called partitions.

Instead of storing everything as one huge table, the data is divided based on a specific rule.

For example, imagine a users table:

users
--------------------------------
id | name  | country
--------------------------------
1  | John  | USA
2  | Ravi  | India
3  | Emma  | UK
4  | Amit  | India
...

You could divide this table into smaller partitions.

For example:

Users Table
     │
     ├── Partition 1
     ├── Partition 2
     ├── Partition 3
     └── Partition 4

Each partition contains only a portion of the total data.

Types of Database Partitioning

There are several common ways to partition data.

1. Range Partitioning

In range partitioning, data is divided based on a range of values.

For example:

User IDs

1 – 1,000,000       → Partition 1
1,000,001 – 2,000,000 → Partition 2
2,000,001 – 3,000,000 → Partition 3

Another common example is date-based partitioning.

Orders

January 2026 → Partition 1
February 2026 → Partition 2
March 2026 → Partition 3

This works especially well for time-series data.

For example:

Logs
Transactions
Orders
Analytics events

Example

SELECT *
FROM orders
WHERE created_at >= '2026-08-01'
AND created_at < '2026-09-01';

The database may only need to search the August partition instead of scanning the entire orders table.

This is known as partition pruning.

2. Hash Partitioning

In hash partitioning, a hash function decides where the data goes.

For example:

hash(user_id) % 4

This could distribute users like this:

User 101 → Partition 1
User 202 → Partition 3
User 303 → Partition 2
User 404 → Partition 4

Architecture:

                Users
                  │
                  ▼
            Hash Function
                  │
        ┌─────────┼─────────┐
        ▼         ▼         ▼
   Partition 1 Partition 2 Partition 3

The main advantage is that data can be distributed more evenly.

This helps prevent one partition from becoming significantly larger than others.

3. List Partitioning

In list partitioning, data is divided based on specific values.

For example:

India       → Partition 1
USA         → Partition 2
UK          → Partition 3
Other       → Partition 4

This can be useful when data naturally belongs to different categories or regions.

What Is Database Sharding?

Sharding is a form of horizontal partitioning where data is distributed across multiple independent database servers.

Instead of:

           One Large Database

You have:

                  Application
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
      Database      Database      Database
      Shard 1       Shard 2       Shard 3

Each shard stores only part of the total dataset.

For example:

Users 1 – 10M      → Shard 1
Users 10M – 20M    → Shard 2
Users 20M – 30M    → Shard 3

Now, instead of one database handling everything, the workload is distributed.

Partitioning vs Sharding

The terms are sometimes used interchangeably, but there is an important difference.

Feature	Partitioning	Sharding
Data split	Yes	Yes
Multiple servers	Not always	Usually
Database manages split	Often	Often handled by application/infrastructure
Main goal	Improve performance and manageability	Scale horizontally
Complexity	Lower	Higher

A simple way to remember it:

Partitioning splits data. Sharding distributes those splits across multiple database servers.

How Does Sharding Work?

A sharded system needs a shard key.

A shard key determines where a piece of data should be stored.

For example:

shard = user_id % 4

Then:

User ID 101 → Shard 1
User ID 102 → Shard 2
User ID 103 → Shard 3
User ID 104 → Shard 4

Architecture:

                   Application
                        │
                        ▼
                 Shard Router
                        │
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
     Shard 1          Shard 2          Shard 3
   Users A-F        Users G-M        Users N-Z

When a request arrives, the system determines which shard contains the required data.

Choosing a Good Shard Key

Choosing the right shard key is one of the most important decisions in a sharded architecture.

A good shard key should:

Distribute data evenly
Distribute traffic evenly
Be frequently available in queries
Avoid creating hotspots
Support future growth

For example, using user_id is often a good choice because many operations are user-specific.

Get user profile
Get user posts
Get user settings
Get user notifications

All of these requests can potentially be routed using the user's ID.

The Hot Shard Problem

Imagine a social media application where users are sharded by celebrity accounts.

A few celebrity accounts may generate millions of requests.

Shard 1 → 100K requests/sec
Shard 2 → 5K requests/sec
Shard 3 → 6K requests/sec

Shard 1 becomes overloaded while the other servers remain mostly idle.

This is called a hot shard or hotspot.

A poor shard key can cause:

Uneven storage
Uneven traffic
Slow requests
Server overload

This is why shard key selection is critical.

Example: Sharding a Social Media Application

Imagine we have 100 million users.

Instead of storing everyone in one database:

                  Users DB
               100 Million Users

We divide them into four shards.

                 User Service
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
       Shard 1     Shard 2     Shard 3
       25M Users    25M Users   25M Users
                      │
                   Shard 4
                   25M Users

A routing layer decides where each user belongs.

For example:

user_id = 12345

12345 % 4 = 1

→ Send request to Shard 1

The application can now handle more data by adding more shards.

Challenges of Database Sharding

Sharding solves scaling problems, but it also introduces complexity.

1. Cross-Shard Queries

Imagine you want to run:

SELECT *
FROM users
ORDER BY created_at DESC;

If users are distributed across multiple shards, the system may need to query every shard.

Shard 1 ─┐
Shard 2 ─┼──→ Combine Results
Shard 3 ─┤
Shard 4 ─┘

This can be expensive and slow.

2. Joins Become Difficult

Suppose:

Users → Shard 1
Orders → Shard 2

A query like:

SELECT *
FROM users
JOIN orders
ON users.id = orders.user_id;

becomes much harder when the data exists on different servers.

Distributed joins are usually more expensive than joins within a single database.

3. Rebalancing Data

Suppose you initially have:

4 Shards

Later, your application grows and you need:

8 Shards

Now, some data may need to move.

Shard 1 → Split
Shard 2 → Split
Shard 3 → Split
Shard 4 → Split

Moving large amounts of data can be complex and risky.

This process is called resharding or rebalancing.

4. Distributed Transactions

Transactions are simple when all data exists in one database.

For example:

Transfer Money

Account A
   ↓
Account B

But if Account A and Account B are stored on different shards, maintaining consistency becomes more complicated.

You may need distributed transaction strategies such as:

Two-phase commit
Saga pattern
Event-driven workflows

When Should You Use Partitioning?

Partitioning is useful when:

A table has grown very large
Queries frequently target specific ranges
You have time-based data
You want faster query performance
You need easier data cleanup

For example, log data can be partitioned by month:

Logs_2026_January
Logs_2026_February
Logs_2026_March

When old data is no longer needed, you can remove an entire partition instead of deleting millions of individual rows.

When Should You Use Sharding?

Sharding is useful when:

A single database server cannot handle the load
Storage requirements exceed one machine
Write traffic is extremely high
You need horizontal scalability
Your application has millions of active users

However, sharding should not be the first solution.

Before sharding, consider:

Better indexing
Query optimization
Caching
Read replicas
Database partitioning
Vertical scaling

Sharding adds significant operational complexity.

A Realistic Scaling Journey

Most applications don't start with sharding.

A typical evolution looks like this:

Stage 1: Single Database

Application
     │
     ▼
Database

Stage 2: Add Indexes and Optimize Queries

Application
     │
     ▼
Optimized Database

Stage 3: Add Caching

Application
     │
     ├── Cache
     │
     ▼
Database

Stage 4: Add Read Replicas

                Application
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
       Primary    Replica     Replica
       Database   Database    Database

Stage 5: Partition Large Tables

Database
   │
   ├── Partition 1
   ├── Partition 2
   └── Partition 3

Stage 6: Shard the Database

                 Application
                      │
               Shard Router
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
      Shard 1       Shard 2       Shard 3

The key lesson is:

Don't introduce sharding before you actually need it.

Final Thoughts

Database partitioning and sharding are powerful techniques for scaling systems that handle massive amounts of data.

Partitioning helps organize and optimize large datasets by splitting them into smaller logical pieces.

Sharding takes this further by distributing data across multiple database servers, allowing an application to scale horizontally.

But with great scalability comes greater complexity.

You need to carefully think about:

Partition strategy
Shard key selection
Data distribution
Hot shards
Cross-shard queries
Rebalancing
Distributed transactions

The best approach is to start simple.

Optimize your queries, use indexes, add caching and replicas, partition when necessary—and move to sharding only when a single database can no longer handle your application's scale.

Because in system design, the goal isn't to use the most complex architecture.

The goal is to use the simplest architecture that can handle your scale.

Key Takeaways

Partitioning splits large datasets into smaller pieces.
Sharding distributes data across multiple database servers.
Common partitioning strategies include range, hash, and list partitioning.
Choosing the right shard key is critical.
Poor distribution can create hot shards.
Sharding improves scalability but increases system complexity.
Optimize your database before deciding to shard.
Start simple and scale your architecture when the actual requirements demand it.

Rate Limiting: Protecting APIs From Abuse and Traffic Spikes

Tanu Priya — Fri, 21 Aug 2026 08:14:32 +0000

Imagine your API suddenly receives 1 million requests in a few seconds.

Maybe it's a viral product launch.

Maybe a client accidentally created an infinite loop.

Or maybe someone is deliberately trying to overwhelm your system.

Without protection, your servers could become overloaded, response times could increase, and legitimate users could start receiving errors.

This is where rate limiting comes in.

Rate limiting controls how many requests a client can make within a specific period of time.

In this article, we'll understand how rate limiting works, the most common algorithms, where to implement it, how distributed systems handle it, and how to design rate limiting for large-scale APIs.

What Is Rate Limiting?

Rate limiting is a mechanism that restricts the number of requests a client can make during a given time window.

For example:

100 requests / minute

A client can make up to 100 requests during that period.

After reaching the limit:

Request 101
   ↓
Rate Limiter
   ↓
❌ Too Many Requests

The API typically responds with:

HTTP/1.1 429 Too Many Requests

Rate limiting protects your infrastructure while ensuring that one client cannot consume an unreasonable amount of resources.

Why Do We Need Rate Limiting?

Without rate limiting, an API might look like:

Client 1 ───────┐
Client 2 ───────┤
Client 3 ───────┤
Client 4 ───────┼──→ API Servers
Client 5 ───────┤
Client 6 ───────┘

Now imagine one client starts sending thousands of requests per second.

Attacker
   │
   ├── Request
   ├── Request
   ├── Request
   ├── Request
   ├── Request
   └── ...
          ↓
      API Servers

This can lead to:

Increased CPU usage
Higher memory consumption
Database overload
Increased network traffic
Higher infrastructure costs
Slow responses
Service outages

Rate limiting adds a protective layer:

Clients
   ↓
Rate Limiter
   ↓
Allowed Requests
   ↓
API Servers

Rate Limiting vs Throttling

These terms are often used together, but they can represent different behaviors.

Rate Limiting

Restricts how many requests can be made.

100 requests / minute

Requests beyond the limit may be rejected.

Throttling

Controls the rate at which requests are processed.

For example, instead of rejecting everything immediately, the system may slow down processing or queue requests.

A simple distinction:

Rate limiting controls how much traffic is allowed.

Throttling controls how quickly traffic is processed.

A Simple Rate Limiting Example

Suppose an API has this rule:

100 requests / minute / user

A user sends:

Request 1
Request 2
Request 3
...
Request 100

All requests are allowed.

The next request:

Request 101
     ↓
❌ 429 Too Many Requests

After the limit resets, requests can be accepted again.

What Should We Rate Limit?

Not every endpoint needs the same limit.

For example:

GET /products
→ 1000 requests/minute

POST /login
→ 10 requests/minute

POST /payments
→ 30 requests/minute

POST /password-reset
→ 5 requests/hour

Expensive or security-sensitive endpoints generally need stricter limits.

Rate Limiting Strategies

There are several common algorithms used to implement rate limiting.

The most important ones are:

Fixed Window
Sliding Window
Token Bucket
Leaky Bucket

Let's understand each.

1. Fixed Window

The fixed-window algorithm divides time into fixed intervals.

For example:

Limit: 100 requests / minute

The system creates windows:

12:00:00 ───────── 12:01:00
12:01:00 ───────── 12:02:00
12:02:00 ───────── 12:03:00

Within each window:

Counter = 0

Request → Counter = 1
Request → Counter = 2
Request → Counter = 3
...
Request → Counter = 100

Once the counter reaches the limit:

Request 101
    ↓
Rejected

At the next window:

Counter → 0

Advantages

Simple to implement
Easy to understand
Low memory usage

Problem

Fixed windows can create boundary spikes.

For example:

12:00:59 → 100 requests
12:01:00 → 100 requests

A client could potentially send 200 requests in a very short period while staying within two different windows.

2. Sliding Window

A sliding-window algorithm evaluates requests over a continuously moving time period.

For example:

Last 60 seconds

Instead of resetting everything at exactly 12:01:00, the system continuously checks the previous 60 seconds.

Conceptually:

         Current Time
              ↓
───────●────●────●────●────●──────
       ←── Last 60 seconds ──→

The system counts requests within that moving window.

Advantages

More accurate
Reduces boundary spikes
Better traffic control

Trade-off

It can require more memory or more sophisticated data structures depending on the implementation.

3. Token Bucket

The token bucket algorithm is one of the most widely used approaches.

Imagine a bucket that holds tokens.

        Token Generator
              ↓
       ┌─────────────┐
       │ ● ● ● ● ●   │
       │   Token     │
       │   Bucket    │
       └─────────────┘
              ↓
          API Request

Each request consumes a token.

Request
   ↓
Take 1 Token
   ↓
Token Available?
  / \
Yes  No
 ↓    ↓
Allow Reject

Tokens are added to the bucket at a fixed rate.

For example:

Bucket capacity: 100 tokens
Refill rate: 10 tokens/second

A client can temporarily make a burst of requests if tokens have accumulated.

But once the bucket is empty, additional requests are rejected or delayed.

Why Token Bucket Is Useful

It supports both:

Sustained traffic
Controlled bursts

This makes it a popular choice for APIs.

4. Leaky Bucket

The leaky-bucket algorithm behaves more like a queue.

Imagine requests entering a bucket:

Requests
   ↓
┌─────────────┐
│ Request     │
│ Request     │
│ Request     │
│ Request     │
└──────┬──────┘
       ↓
   Fixed Rate
       ↓
      API

Requests are processed at a relatively consistent rate.

If the queue becomes full, new requests may be rejected.

Token Bucket vs Leaky Bucket

A useful distinction is:

Token Bucket

Allows controlled bursts

Leaky Bucket

Produces a smoother processing rate

The right choice depends on your traffic pattern.

Comparing Rate Limiting Algorithms

Algorithm	Main Idea	Burst Support	Complexity
Fixed Window	Fixed time counters	Yes	Low
Sliding Window	Moving time window	Limited	Medium
Token Bucket	Tokens refill over time	Yes	Medium
Leaky Bucket	Process requests at fixed rate	Limited	Medium

There is no universally best algorithm.

The choice depends on whether your system needs simplicity, burst handling, accuracy, or smooth traffic.

Where Should Rate Limiting Be Implemented?

Rate limiting can be implemented at different layers.

Application Layer

Client
 ↓
Application
 ↓
Rate Limiter
 ↓
Database

This gives the application detailed control over users and endpoints.

API Gateway

Client
 ↓
API Gateway
 ↓
Rate Limiter
 ↓
Services

This is useful when multiple services need consistent protection.

CDN / Edge

User
 ↓
Edge
 ↓
Rate Limiter
 ↓
Origin

Rate limiting at the edge can block unwanted traffic before it reaches your infrastructure.

Multiple Layers

Large systems may use several layers:

User
 ↓
CDN
 ↓
API Gateway
 ↓
Service
 ↓
Database

Each layer can have different limits.

What Should the Rate Limit Key Be?

A rate limiter needs to determine who or what is being limited.

Possible keys include:

IP Address

Rate limit per IP

Useful for unauthenticated endpoints.

But many users can share the same public IP.

User ID

Rate limit per user

Useful for authenticated APIs.

API Key

Rate limit per API key

Common for developer-facing APIs.

Endpoint

Rate limit per endpoint

Useful when different APIs have different costs.

Combined Key

For example:

user_id + endpoint

This provides more granular control.

Distributed Rate Limiting

Here's where system design becomes interesting.

Imagine your API has multiple servers:

              Load Balancer
             /      |      \
            ↓       ↓       ↓
        Server 1 Server 2 Server 3

If each server maintains its own counter:

Server 1 → 40 requests
Server 2 → 40 requests
Server 3 → 40 requests

A user could effectively make:

120 requests

even if the intended limit was 100.

The counters are not shared.

Shared Rate Limiter

A common solution is to use a shared, fast data store.

For example:

                 Load Balancer
                /      |      \
               ▼       ▼       ▼
           Server 1 Server 2 Server 3
                \       |       /
                 \      |      /
                   ▼    ▼
                Redis

Now all servers can use the same rate-limit state.

Request
   ↓
Any API Server
   ↓
Shared Counter
   ↓
Redis

This allows the system to enforce a global limit across multiple application instances.

Rate Limiting With Redis

A simplified concept might look like:

Key:
rate:user:123

Value:
87

TTL:
60 seconds

Every request increments the counter.

Request
   ↓
Increment counter
   ↓
Counter <= Limit?
   │
 ┌─┴───┐
Yes   No
 ↓     ↓
Allow Reject

For more sophisticated algorithms, Redis can store timestamps, token counts, or other state.

Atomic operations are important because multiple requests can arrive simultaneously.

Race Conditions

Imagine two requests arrive at exactly the same time.

Both servers read:

Counter = 99

Both think:

99 < 100

Both increment it.

Now the actual count could become inconsistent.

This is why distributed rate limiting needs atomic operations or carefully designed server-side logic.

The rate limiter itself must be safe under high concurrency.

What Response Should the API Return?

When a client exceeds the limit, the standard response is:

429 Too Many Requests

The API can also communicate useful information about when the client can retry.

For example:

Retry-After: 30

This tells the client to wait before trying again.

Well-designed clients should respect these signals instead of immediately retrying.

Rate Limiting and Retry Storms

Imagine a service becomes overloaded.

Clients receive errors and immediately retry.

Those retries create even more traffic.

Service Overloaded
       ↓
     Errors
       ↓
     Clients
       ↓
   Immediate Retry
       ↓
More Traffic
       ↓
More Errors

This can become a retry storm.

Rate limiting works best alongside strategies such as:

Exponential backoff
Jitter
Retry limits
Circuit breakers
Timeouts

The goal is to prevent failures from amplifying themselves.

Rate Limiting vs Authentication

These systems often work together.

For example:

Request
   ↓
Authentication
   ↓
Rate Limiting
   ↓
Authorization
   ↓
Application

Or at an API gateway:

Client
  ↓
API Gateway
  ├── Authentication
  ├── Rate Limiting
  └── Routing
        ↓
      Service

Authentication identifies the client.

Rate limiting controls how much traffic that client can generate.

Authorization determines what the client is allowed to access.

Rate Limiting Expensive Operations

Not every request costs the same.

Consider:

GET /health

versus:

POST /generate-report

The second request may consume significantly more CPU, memory, database resources, or external API calls.

Using the same rate limit for both endpoints may not make sense.

You can assign different limits based on cost:

Health Check
→ High limit

Read API
→ Medium limit

Heavy Computation
→ Low limit

This is sometimes called cost-based rate limiting.

Rate Limiting at Large Scale

A large production architecture might look like:

                       Users
                         │
                         ▼
                       CDN
                         │
                         ▼
                   API Gateway
                         │
                 ┌───────┴───────┐
                 │ Rate Limiter  │
                 └───────┬───────┘
                         │
                  Load Balancer
                         │
             ┌───────────┼───────────┐
             ▼           ▼           ▼
          Server 1    Server 2    Server 3
             │           │           │
             └───────────┼───────────┘
                         ▼
                      Database

A shared store can maintain rate-limit state:

             Servers
                │
                ▼
             Redis
                │
                ▼
        Rate Limit State

This allows rate limiting to work across the entire application cluster.

Common Rate Limiting Mistakes

Some common mistakes include:

Using only in-memory counters with multiple servers
Applying the same limit to every endpoint
Ignoring shared IP addresses
Not handling bursts correctly
Forgetting about concurrent requests
Returning errors without retry information
Allowing clients to retry immediately
Using a single global limit for different user tiers
Not monitoring rejected requests
Making the rate limiter itself a single point of failure

Rate limiting is infrastructure.

It needs to scale alongside the system it protects.

Rate Limiting for Different Users

Not every user needs the same limits.

For example:

Free Plan
→ 100 requests/minute

Pro Plan
→ 1,000 requests/minute

Enterprise
→ Custom limits

This allows APIs to support different usage levels.

The rate-limit key could include:

user_id + plan + endpoint

This gives the system more granular control.

The Big Picture

Rate limiting is essentially a traffic-control mechanism for your APIs.

Without it:

Clients
   ↓
API
   ↓
Overload

With it:

Clients
   ↓
Rate Limiter
   ↓
Allowed Traffic
   ↓
API
   ↓
Database

The rate limiter acts as a protective boundary between unpredictable client traffic and your infrastructure.

Key Takeaway

Rate limiting isn't just about blocking excessive requests.

It's about making your system more predictable, resilient, and fair.

A good rate-limiting strategy can:

Protect APIs from abuse
Handle traffic spikes
Prevent resource exhaustion
Protect databases
Improve system stability
Provide fair usage across clients
Reduce infrastructure costs

For small systems, a simple fixed-window limiter may be enough.

For larger distributed systems, you may need token buckets, shared Redis state, API gateways, edge protection, and carefully designed retry behavior.

The goal isn't to stop traffic. The goal is to control traffic so your system can keep serving legitimate users reliably.

Authentication at Scale: Sessions, JWT, Tokens, OAuth & Distributed Auth

Tanu Priya — Thu, 20 Aug 2026 11:03:09 +0000

Authentication looks simple when an application has a few users.

A user enters an email and password, the server verifies the credentials, and the user is logged in.

But what happens when your application has millions of users, thousands of requests per second, multiple servers, mobile apps, and services distributed across different regions?

Authentication becomes a system-design problem.

You need to answer questions like:

Where should authentication state be stored?
How do multiple servers know that a user is logged in?
Should you use sessions or JWTs?
How should tokens expire?
How do you revoke access?
How does OAuth work?
How do microservices verify users?
How do you scale authentication across regions?

Let's break it down.

What Is Authentication?

Authentication answers one fundamental question:

"Who are you?"

For example:

User
  ↓
Email + Password
  ↓
Authentication Server
  ↓
Identity Verified
  ↓
Authenticated User

Authentication is different from authorization.

Authentication

Determines who the user is.

Who are you?
→ User 123

Authorization

Determines what the user is allowed to do.

What can User 123 access?
→ Read orders
→ Create orders
→ Cannot access admin panel

A scalable system usually needs both.

Basic Authentication Flow

A simple login system might work like this:

User
  │
  │ Email + Password
  ▼
Auth Server
  │
  │ Verify Credentials
  ▼
User Database
  │
  │ Valid
  ▼
Session / Token
  │
  ▼
User

After login, the client needs some way to prove its identity on future requests.

This is where sessions and tokens come in.

Session-Based Authentication

With session-based authentication, the server creates a session after successful login.

For example:

User
  ↓
Login
  ↓
Server
  ↓
Create Session
  ↓
Session ID
  ↓
Browser Cookie

The browser might store:

session_id=abc123

On future requests:

User
  ↓
Cookie: session_id=abc123
  ↓
Server
  ↓
Session Store
  ↓
User Identity

The server uses the session ID to find the user's authentication state.

How Sessions Work at Scale

A single server can store sessions in memory:

User
 ↓
Server
 ↓
RAM

But this creates a problem when multiple servers are introduced.

Imagine:

             Load Balancer
              /        \
             ↓          ↓
        Server 1     Server 2
           │             │
        Session A      Session B

A user logs in through Server 1.

The session exists on Server 1.

The next request might go to Server 2.

Server 2 doesn't know about the session.

This is a problem.

Shared Session Store

One solution is to move sessions into a shared data store.

For example:

                Load Balancer
                /           \
               ▼             ▼
          Server 1       Server 2
               \             /
                \           /
                  ▼       ▼
                Session Store

The session store could be a distributed in-memory database such as Redis.

Now every application server can access the same session state.

Request
   ↓
Any Server
   ↓
Shared Session Store
   ↓
User Session

This makes session-based authentication much easier to scale horizontally.

Advantages of Sessions

Sessions have several useful properties:

Easy to invalidate
Server controls authentication state
Sensitive authentication data doesn't need to be stored directly in the browser
Logout can invalidate the session
Good fit for traditional web applications

But sessions also have a trade-off:

The server needs to maintain authentication state.

At very large scale, that shared state becomes an important infrastructure component.

What Is a Token?

A token is a piece of data that represents an authenticated identity or authorization.

Instead of storing all authentication state on the server, the client can present a token with its requests.

For example:

User
 ↓
Login
 ↓
Auth Server
 ↓
Access Token
 ↓
Client

Then:

Client
 ↓
Authorization: Bearer <token>
 ↓
API Server
 ↓
Validate Token
 ↓
Request Allowed

Tokens are commonly used in APIs, mobile applications, and distributed systems.

JWT Authentication

One popular token format is JWT (JSON Web Token).

A JWT typically contains information such as:

Header
Payload
Signature

Conceptually:

JWT
 ├── Header
 ├── Payload
 └── Signature

The payload might contain claims such as:

{
  "sub": "user123",
  "role": "user",
  "exp": 1780000000
}

The token is signed so the server can verify that it was issued by a trusted authority and hasn't been modified.

JWT Authentication Flow

A simplified JWT flow looks like this:

User
  ↓
Login
  ↓
Authentication Server
  ↓
JWT
  ↓
Client
  ↓
API Request
  ↓
Authorization: Bearer JWT
  ↓
API Server
  ↓
Verify Signature
  ↓
Allow Request

One major benefit is that the server doesn't necessarily need to look up a session for every request.

Sessions vs JWT

The difference can be summarized like this:

Sessions	JWT
Server maintains session state	Token carries claims
Session ID sent by client	JWT sent by client
Easy revocation	Revocation requires additional strategy
Requires shared session storage at scale	Can be validated independently
Common for web applications	Common for APIs and distributed systems
Server controls session state	Client carries the token

Neither is universally better.

The right choice depends on the system.

Stateless Authentication

JWTs are often used to create a more stateless authentication layer.

For example:

                 Load Balancer
                /      |      \
               ▼       ▼       ▼
           Server 1 Server 2 Server 3
              │        │        │
              └──── Verify JWT ─┘

Each server can independently validate the token.

There doesn't necessarily need to be a centralized session lookup for every request.

This can simplify horizontal scaling.

But "stateless" doesn't mean there is no authentication infrastructure.

You still need to manage:

Token issuance
Signing keys
Expiration
Refresh tokens
Revocation
Key rotation
User sessions

Access Tokens and Refresh Tokens

A common authentication design uses two types of tokens.

Access Token

Used to access APIs.

Client
 ↓
Access Token
 ↓
API

Access tokens are usually short-lived.

Refresh Token

Used to obtain a new access token.

Refresh Token
      ↓
Authentication Server
      ↓
New Access Token

The flow becomes:

Login
  ↓
Access Token + Refresh Token
  ↓
Client
  │
  ├── Access Token → API
  │
  └── Refresh Token → Auth Server
                           ↓
                    New Access Token

Short-lived access tokens reduce the impact of a stolen token.

Why Not Make Access Tokens Last Forever?

Suppose an access token remains valid for 30 days.

If an attacker obtains it, they may be able to use it for the entire validity period.

Shorter expiration reduces this window.

For example:

Access Token
   ↓
Short Lifetime
   ↓
Expires
   ↓
Refresh Token
   ↓
New Access Token

The exact expiration strategy depends on the application's security and usability requirements.

What Is OAuth?

OAuth is a framework for delegated authorization.

A common example is:

"Continue with Google"

Instead of giving your application your Google password, the user authenticates with Google and grants the application permission to access specific information.

A simplified flow:

User
  ↓
Your Application
  ↓
OAuth Provider
  ↓
User Authentication
  ↓
Authorization
  ↓
Authorization Code
  ↓
Your Backend
  ↓
Access Token

OAuth is especially useful when applications need access to resources controlled by another identity provider.

OAuth vs Authentication

OAuth is primarily about authorization, not simply proving identity.

For user authentication, systems commonly use OpenID Connect (OIDC) on top of OAuth 2.0.

Conceptually:

OAuth
  ↓
Delegated Authorization

OIDC
  ↓
Authentication / Identity

This distinction is important when designing authentication systems.

Authentication in Microservices

Now imagine a system with multiple services:

                API Gateway
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
   User Service Order Service Payment Service

Should every service implement login and password verification?

Usually, no.

A better approach is to centralize identity management.

                 Identity Provider
                       │
                       ▼
                  Access Token
                       │
                       ▼
                  API Gateway
                       │
       ┌───────────────┼───────────────┐
       ▼               ▼               ▼
   User Service    Order Service   Payment Service

Services can validate the authenticated identity and authorization information rather than each implementing its own login system.

Authentication at the API Gateway

An API Gateway can perform authentication before forwarding requests.

For example:

Client
  ↓
API Gateway
  ↓
Validate Token
  ↓
Authenticated?
  │
 ┌┴─────────┐
 No         Yes
 ↓           ↓
401        Service

This provides a centralized entry point.

However, internal services should still be designed carefully rather than blindly trusting every request from the network.

Distributed Authentication

At large scale, authentication infrastructure itself may be distributed.

A simplified architecture could look like:

                    Users
                      │
                      ▼
                Global Routing
                      │
          ┌───────────┴───────────┐
          ▼                       ▼
     Auth Region A           Auth Region B
          │                       │
          ▼                       ▼
      Auth Servers            Auth Servers
          │                       │
          └───────────┬───────────┘
                      ▼
               User / Identity Data

Now additional challenges appear:

Regional availability
Data replication
Key management
Token validation
Session consistency
Failover
Clock synchronization
Rate limiting

Authentication becomes part of the overall distributed-system architecture.

What Happens If an Authentication Server Goes Down?

Authentication is often a critical dependency.

If users cannot authenticate, they may not be able to access the application.

Therefore, authentication infrastructure should avoid having a single point of failure.

For example:

                 Load Balancer
                /      |      \
               ▼       ▼       ▼
            Auth 1   Auth 2   Auth 3
               │       │       │
               └───────┼───────┘
                       ▼
                 Shared Data

Multiple authentication servers can provide redundancy.

Health checks and failover mechanisms can route traffic away from unhealthy instances.

Token Validation at Scale

Suppose your application receives millions of API requests.

You don't want every request to perform an expensive remote authentication lookup if it can be avoided.

A common approach is to use signed tokens that services can validate locally.

Request
  ↓
Service
  ↓
Verify Token Signature
  ↓
Check Claims
  ↓
Allow / Reject

This reduces dependency on a centralized authentication lookup for every request.

However, services still need access to trusted signing keys.

Key Management

If JWTs or other signed tokens are used, signing keys become critical infrastructure.

A simplified flow:

Identity Provider
       │
       │ Signs Token
       ▼
    JWT Token
       │
       ▼
   Application
       │
       │ Verify Signature
       ▼
    Valid Token

Keys should be protected carefully.

Large systems may use mechanisms such as:

Key rotation
Key versioning
Secure key storage
Public/private key pairs
Key distribution endpoints

The goal is to avoid making a single long-lived secret a permanent point of failure.

Logout and Token Revocation

Logging out sounds simple:

User → Logout

But with stateless tokens, there's an important question:

What happens to an access token that has already been issued?

If the token remains valid until expiration, simply deleting it from the client doesn't necessarily invalidate it everywhere.

Possible strategies include:

Short-lived access tokens
Refresh-token revocation
Session tracking
Token deny lists
Token versioning
Centralized authorization checks

The right approach depends on how quickly the system needs to revoke access.

Authentication Rate Limiting

Authentication endpoints are attractive targets for attackers.

For example:

POST /login
POST /signup
POST /forgot-password
POST /refresh-token

These endpoints should typically have appropriate protections such as rate limiting and abuse detection.

A simplified flow:

Login Request
     ↓
Rate Limiter
     ↓
Authentication
     ↓
Success / Failure

This helps prevent excessive login attempts and protects authentication infrastructure from abuse.

A Scalable Authentication Architecture

Putting the concepts together:

                         Users
                           │
                           ▼
                     Load Balancer
                           │
                           ▼
                      API Gateway
                           │
                    Token Validation
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
      User Service     Order Service    Payment Service
          │                │                │
          └────────────────┼────────────────┘
                           │
                      Databases

Alongside the application:

                 Identity Provider
                       │
              ┌────────┴────────┐
              ▼                 ▼
         Access Tokens     Refresh Tokens

This separates identity management from application business logic.

Common Authentication Mistakes

Some common architectural mistakes include:

Storing passwords insecurely
Making access tokens live too long
Putting sensitive information into tokens
Sharing authentication secrets carelessly
Having a single authentication server
Not planning for token revocation
Ignoring key rotation
Treating OAuth as the same thing as authentication
Trusting internal services without proper controls
Building authentication independently in every microservice

Authentication is security-critical infrastructure.

It should be designed accordingly.

How Should You Choose?

There isn't one authentication strategy that works for every system.

Small Traditional Web Application

A server-side session can be a simple and effective choice.

Browser
  ↓
Session Cookie
  ↓
Server
  ↓
Session Store

Mobile or API-Heavy Application

Token-based authentication may be more appropriate.

Client
  ↓
Access Token
  ↓
API

Distributed Microservices

A centralized identity provider with signed access tokens can work well.

Identity Provider
       ↓
Access Token
       ↓
API Gateway
       ↓
Microservices

Social Login

OAuth + OpenID Connect is commonly used.

Application
     ↓
Identity Provider
     ↓
User Authentication
     ↓
Application

The Big Picture

Authentication at scale is not just about login forms.

It is about creating a reliable identity system that works across:

Multiple servers
Multiple services
Multiple regions
Web applications
Mobile applications
APIs
Third-party identity providers

A simplified evolution might look like:

Simple App
    ↓
Sessions
    ↓
Shared Session Store
    ↓
Token-Based APIs
    ↓
Identity Provider
    ↓
Distributed Authentication

The architecture should evolve as the system's requirements grow.

Key Takeaway

There is no universal winner between sessions, JWTs, and tokens.

Each approach solves a different problem.

Sessions provide centralized server-side control.

JWTs can make token validation easier across distributed services.

Access and refresh tokens provide a flexible pattern for API authentication.

OAuth and OpenID Connect make delegated access and external identity providers possible.

And at large scale, authentication becomes distributed infrastructure that must be designed for security, availability, scalability, and failure.

Authentication isn't just about proving who the user is. At scale, it's about reliably proving identity across an entire distributed system.

DEV Community: Tanu Priya

Virtual DOM vs Real DOM: Is the Virtual DOM Actually Faster?

1. What Is the Real DOM?

2. Why Does the DOM Have a Reputation for Being Slow?

3. So What Is the Virtual DOM?

4. The Biggest Myth: "The Virtual DOM Is Faster"

5. The Real Problem: Managing Complex UI State

6. Declarative UI Changes the Way We Think

Imperative

Declarative

7. How React Uses the Virtual DOM

8. But Doesn't Reconciliation Add Extra Work?

9. Can Direct DOM Manipulation Be Faster?

10. The Trade-Off React Makes

11. A Better Comparison: Imperative vs Declarative

12. Is the Virtual DOM the Fastest Rendering Strategy?

13. React's Strength Is Bigger Than the Virtual DOM

14. The Virtual DOM Doesn't Make Expensive JavaScript Disappear

15. What Should You Actually Optimize?

State Architecture

Re-render Behavior

Expensive Calculations

Large Lists

Network Performance

Images and Assets

Bundle Size

Real User Experience

16. The Right Mental Model

17. So, Is the Virtual DOM Actually Faster?

Not by itself.

18. The One-Sentence Explanation

Final Takeaway

Why Does Your React App Re-render So Much?

What Does a Re-render Actually Mean?

What Causes a Component to Render?

1. Its State Changes

2. Its Parent Renders

3. Its Props Change

4. A Context Value Changes

5. State Used by a Custom Hook Changes

The Biggest Source of Unnecessary Work: State in the Wrong Place

Why "Re-render" Doesn't Mean "DOM Update"

What Is Reconciliation?

What Happens During the Commit?

What About the Browser?

Why Can Re-renders Be Expensive?

What About React.memo?

The Hidden Problem: New Object References

So What Is useCallback For?

And What About useMemo?

The Most Common React Performance Mistake

How to Investigate a Re-render

1. What caused it?

2. Does the component actually need that state?

3. Is the render expensive?

4. Can the component structure be improved?

5. Would memoization actually help?

The React Performance Mindset

The Mental Model to Remember

Final Takeaway

What Really Happens When React State Changes?

The Example

1. The State Update Is Scheduled

2. React Renders the Component

3. React Determines What Changed

4. React Commits the Changes

5. Then the Browser Has to Render It

6. Render Doesn't Always Mean DOM Changes

7. Why Does a Component Re-render?

8. What About the Virtual DOM?

9. Declarative vs Imperative

10. What Happens With Multiple State Updates?

11. Does React Rebuild Everything?

12. Why Can Re-renders Still Be Expensive?

13. The Complete Journey

The Mental Model You Should Remember

1. State updates are not DOM commands

2. Re-rendering does not mean rebuilding the entire DOM

3. Rendering does not necessarily mean the DOM changes

Final Takeaway

What About `React.memo`?

So What Is `useCallback` For?

And What About `useMemo`?

7. Why Does the Promise Run Before `setTimeout`?

9. Does `setTimeout(..., 0)` Mean "Run Immediately"?