DEV Community: Sri Balaji

Core Web Vitals & Frontend Performance

Sri Balaji — Tue, 13 Oct 2026 17:52:46 +0000

⚡ TL;DR: Your laptop lies about speed. Measure what real users feel with LCP, INP, and CLS, then spend effort on the few highest-leverage fixes that actually move those numbers instead of micro-optimizing things users never notice.

The site that lied to you
The principle: measure what users feel
The page-load timeline, mapped to the user
The three vitals at a glance
Two fixes that pay for themselves
Common mistakes that cost hours
Takeaways
Where to go next

The site that lied to you

You build a page. On your laptop it is instant, text snaps in, images pop, buttons respond the moment you click. You ship it. Then a user opens it on a three-year-old Android phone over patchy mobile data, and it is a different product entirely: a blank screen for two seconds, then a hero image that shoves the headline down just as they reach for it, then a tap that does nothing for half a second because the main thread is busy parsing your JavaScript.

Nothing changed about your code between those two experiences. What changed was the device and the network. Your laptop has a fast CPU, a fast connection, and a warm cache. Most of your users have none of those. The gap between "works on my machine" and "works for my users" is exactly the gap Core Web Vitals were invented to close.

📌 Who this is for: Junior frontend engineers who can build a working page but have never deliberately measured its speed. If you have ever shipped something that felt fast to you and slow to everyone else, this is the article that explains why, and what to do about it.

The principle: measure what users feel

Measure what users actually feel, on the devices they actually use, not what your laptop tells you on a good day.

The one rule of performance work

Performance is not a single number like "page weight" or "load time". It is a sequence of moments the user lives through: Can I see it yet? Is it stable while I read? Does it respond when I touch it? Core Web Vitals are three metrics, each one standing in for one of those felt moments. They are deliberately user-centric, they do not care how clever your build is, only what the human in front of the screen experiences.

In the real world	In tech
How fast the main dish actually arrives at your table	LCP, when the largest, most meaningful content appears
The waiter responding quickly when you ask for the bill	INP, how fast the page reacts to your interactions
Your table not wobbling and spilling your drink mid-meal	CLS, the layout staying put instead of jumping around

Loading a page is like being seated at a restaurant.

A restaurant where the food is fast, the staff are responsive, and the table is steady feels good even if you cannot name why. Get any one of the three wrong and the whole experience sours, exactly how a page with great LCP but a janky layout still feels broken.

The page-load timeline, mapped to the user

Here is one page load as the user lives it, left to right in time. Each vital attaches to a different moment of that journey, load, stability, and interactivity are not the same event and you cannot fix them with the same lever.

A single page load over time: each Core Web Vital maps to a distinct moment the user perceives.

Notice the order. LCP happens early (loading), CLS accumulates across the whole load (stability), and INP is measured every time the user interacts (responsiveness). You optimize them in roughly that sequence, but you only know which one to attack after you measure.

Measure: Run Lighthouse in Chrome DevTools, but more importantly pull field data from the PageSpeed Insights report or the CrUX dashboard. Field data is real users on real devices, that is the truth. Lab data is a controlled simulation; useful for debugging, dangerous as your only source.
Find the biggest offender: Look at which of the three vitals is in the "poor" or "needs improvement" band. Do not optimize a green metric. In the Lighthouse report, expand the failing metric to see what element or script is responsible, it names the exact LCP element and the longest tasks blocking the main thread.
Fix one thing: Apply the highest-leverage change for that specific vital, an oversized hero image, a render-blocking bundle, an unsized embed. Change one variable so you can attribute the result.
Re-measure: Re-run the same measurement and confirm the number actually moved. Then repeat from step two on the next-worst metric. Performance work is a loop, not a one-time pass, and field data updates over 28 days, so real-world wins take time to show.

The three vitals at a glance

Each vital has published thresholds. Google grades the 75th percentile of your users, meaning three out of four real visits must hit the "good" bar before the metric counts as passing. Optimizing for the average hides your slowest users; the 75th percentile is what forces you to care about that mid-range phone.

Metric	What it measures	Good threshold	Top fixes
LCP (Largest Contentful Paint)	Loading, how long until the largest visible element (usually a hero image or headline block) is painted	≤ 2.5 s	Optimize/compress the LCP image, preload it, use a CDN, remove render-blocking CSS/JS, serve modern formats (WebP/AVIF)
INP (Interaction to Next Paint)	Interactivity, how quickly the page visually responds to taps, clicks, and key presses across the whole visit	≤ 200 ms	Break up long tasks, reduce main-thread JS, code-split, defer non-critical scripts, debounce expensive handlers
CLS (Cumulative Layout Shift)	Visual stability, how much content unexpectedly jumps around as the page loads	≤ 0.1	Set width/height on images & video, reserve space for ads/embeds, avoid injecting content above existing content, preload fonts

The three Core Web Vitals, their thresholds, and where to spend your effort.

The bands are the same shape for all three: good is the threshold above, needs improvement is the grey middle, and poor is anything past the second cutoff (LCP > 4 s, INP > 500 ms, CLS > 0.25). INP replaced the older FID metric in 2024, FID only measured the first interaction's delay, while INP watches every interaction, which is a far harsher and more honest test.

Two fixes that pay for themselves

The two highest-leverage techniques for a junior to reach for are lazy-loading offscreen images (helps LCP and total bytes) and code-splitting heavy components (helps INP by shrinking the JavaScript the main thread must parse upfront). Both are one-liners in modern stacks.

Lazy-load images you cannot see yet

An image below the fold does not need to load before the user scrolls to it. The native loading="lazy" attribute defers it for free. The critical detail: always set width and height so the browser reserves the space, this is what prevents the layout shift (CLS) when the image finally arrives. One important exception: your LCP image (the hero) should not be lazy, load it eagerly, even preload it.

below-the-fold.html

<!-- Hero image: the LCP element. Load it eagerly + hint high priority. -->
<img
  src="/hero.avif"
  width="1200"
  height="600"
  fetchpriority="high"
  alt="Product dashboard"
/>

<!-- Offscreen images: defer until the user scrolls near them. -->
<!-- width + height reserve the box so nothing jumps (protects CLS). -->
<img
  src="/screenshot.avif"
  width="800"
  height="450"
  loading="lazy"
  alt="Feature screenshot"
/>

Code-split so the main thread can breathe

A 500 KB JavaScript bundle has to be downloaded, parsed, and executed before the page is interactive, and parsing JS is one of the most expensive things a phone's CPU does. If a heavy component (a chart library, a rich editor, a modal) is not needed on first paint, load it on demand with a dynamic import. The bundler splits it into a separate chunk that only ships when it is actually used.

Dashboard.tsx

import { lazy, Suspense, useState } from "react";

// Heavy charting lib is NOT in the initial bundle.
// It downloads only when <Chart /> first renders.
const Chart = lazy(() => import("./HeavyChart"));

export function Dashboard() {
  const [showChart, setShowChart] = useState(false);

  return (
    <section>
      <button onClick={() => setShowChart(true)}>Show analytics</button>

      {showChart && (
        <Suspense fallback={<p>Loading chart…</p>}>
          <Chart />
        </Suspense>
      )}
    </section>
  );
}

💡 Tip: Code-splitting is not just for big libraries. Route-level splitting, loading each page's code only when the user navigates to it, is often the single biggest INP and LCP win, and most frameworks (Next.js, React Router) do it for you automatically once you stop importing everything into one shared bundle.

Common mistakes that cost hours

Optimizing the wrong thing. Spending a day shaving 50 ms off an already-green LCP while INP sits in the red. Always fix the worst metric first, measure before you touch anything.
Shipping huge JavaScript bundles. Importing an entire library to use one function, or bundling every route's code into one file. This is the number-one cause of bad INP on real devices, your laptop hides it, the phone does not.
Unsized images and embeds causing CLS. An <img> or ad iframe with no width/height reserves zero space, so content reflows and jumps when it loads. Cheap to fix, and a top source of "why does the page keep moving" complaints.
Lab-only testing. Trusting a single Lighthouse run on your fast laptop and declaring victory. Lab data is for debugging; field data (real users, 75th percentile) is the score that ships. Always check both.
Ignoring fonts. A web font that swaps in late pushes text around (CLS) or hides it entirely (delayed LCP). Preload critical fonts and use font-display: swap with a matched fallback.

Takeaways

The whole article in seven lines

Performance is what users feel, on their devices, not what your laptop reports.
Three vitals: LCP (loading, ≤ 2.5 s), INP (interactivity, ≤ 200 ms), CLS (stability, ≤ 0.1).
Always measure with field data at the 75th percentile, not just a lab run.
Loop: measure → find the worst metric → fix one thing → re-measure → repeat.
Lazy-load offscreen images (but eager-load the LCP hero) and always set width/height.
Code-split heavy components with dynamic imports so the main thread parses less JS.
Most CLS bugs are unsized images, embeds, and late fonts, reserve the space.

Where to go next

Core Web Vitals make the most sense once you understand why the browser behaves the way it does. If you have not yet, read How the Browser Renders a Page, the render path is exactly what LCP and CLS are measuring. Then Frontend Build Tooling & Bundling shows you the mechanics behind code-splitting and shrinking the bundles that wreck INP.

Follow the full Frontend Engineer career path to put performance in context with the rest of the role.
Re-read How the Browser Renders a Page, render-blocking resources and layout are the root of LCP and CLS.
Use Frontend Build Tooling & Bundling to set up route-level code-splitting in your own project.
Run your own site through PageSpeed Insights today and write down which of the three vitals is your worst, that is your first fix.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.

State Management in Frontend Apps

Sri Balaji — Mon, 12 Oct 2026 20:03:52 +0000

⚡ TL;DR: Stop reaching for a global store too early. Identify which of the five kinds of state you have and pick the narrowest tool that works, and never manage server state as if it were client state.

You wired up a global store for a toggle
Pick the narrowest scope that works
The five kinds of state, by scope
A cheat sheet: state type to tool
Local state vs a server-cache hook in code
Server state is not client state
Common mistakes that cost hours
Takeaways
Where to go next

You wired up a global store for a toggle

A teammate opens the codebase and finds a Redux store, three slices, a middleware, and a set of action creators. They follow the wiring to see what important, app-wide thing it manages. The answer: whether a dropdown menu is open. One boolean. It lives in a global store, reachable from every component in the app, persisted across routes, traced through DevTools, to remember if a little arrow points up or down.

This is the most common failure in frontend, and it is not a beginner mistake, senior teams do it constantly. State management has a reputation for being hard, so people reach for the heaviest tool they know first, before they have a problem that needs it. The result is apps where a one-line change touches four files, and where nobody can tell which state actually matters.

The skill is not learning Redux, Zustand, or Jotai. The skill is knowing what kind of state you have and putting it in the smallest place that works. Most state does not belong in a global store. A lot of it is not even client state at all.

📌 Who this is for: Frontend developers, comfortable with JavaScript and React components, who keep hearing "just use a state library" and want a framework for deciding where each piece of state should live, not which library to install. No prior Redux or Zustand experience assumed.

Pick the narrowest scope that works

State should live in the narrowest scope that still works, and move outward only when something outside that scope genuinely needs it.

The one rule this whole article is about

Almost every state decision is a question of scope: who needs to read this value, and who needs to change it? If only one component cares, it is local. If two siblings care, lift it to their parent. If the whole app cares, it might be global. The mistake is starting at the widest scope "just in case", you pay the complexity cost forever for a need that usually never arrives.

In the real world	In tech
A reminder only you need, on a sticky note on your own desk	Local UI state, useState inside one component
A note your deskmate also needs, stuck where you both sit	Lifted state, held in the shared parent of two components
A policy the whole company must see, on the lobby noticeboard	Global state, a store every component can read
Putting your lunch order on the company noticeboard	A toggle in a global Redux store, wrong desk entirely

Where you write a note depends on who needs to read it.

Keep the sticky note on the right desk. Most of what gets pinned to the global noticeboard is a private reminder that only one component ever reads, it just got promoted out of habit.

The five kinds of state, by scope

Before you can choose a tool, you have to name what you are holding. Almost everything falls into one of five buckets, ordered from narrowest scope to widest. The further right you go, the more tools and ceremony you take on, so the goal is always to stay as far left as the requirement allows.

State types by scope, start at the left, move right only when forced.

Does only one component use it?: Keep it local with useState. A form input, a hover flag, an open/closed toggle, these almost never leave the component that owns them. This is where most state should stay.
Do a couple of nearby components need it?: Lift it to their closest common parent and pass it down as props. Two siblings sharing a selected tab? The tab index lives in the parent. No library required.
Does genuinely everything need it, far apart in the tree?: Now consider Context or a small global store, for things like the signed-in user, theme, or feature flags. The bar is high: it must be needed in many distant places and rarely change.
Does the data actually live on a server?: Stop. This is not client state. Use a server-state library (TanStack Query, SWR, RTK Query) that handles fetching, caching, and refetching. Do not copy it into a store.
Should the value survive a refresh or be shareable via link?: Put it in the URL. A search query, active filter, page number, or selected tab often belongs in search params so a copied link reproduces the exact view.

A cheat sheet: state type to tool

Map each kind of state to its example and the simplest tool that fits. If you can answer "what kind of state is this?" you have already answered "what should I reach for?". Notice how few rows actually call for a global store.

State type	Example	The right tool
Local UI	Input value, dropdown open, hover, an accordion's expanded panel	`useState` / `useReducer`
Lifted / shared	Selected row two sibling panels both read	State in the common parent + props
Global app	Signed-in user, theme, feature flags	Context, or a small store (Zustand)
Server-cache	Product list, user profile, anything from an API	TanStack Query / SWR / RTK Query
URL	Search term, filters, page number, active tab	Router search params (`useSearchParams`)

Pick the row first, the tool second.

💡 Tip: When in doubt, default to local. It is trivial to lift state upward later when a second component needs it. Pulling a tangle of global state back down once everything depends on it is a refactor nobody volunteers for.

Local state vs a server-cache hook in code

Here is the contrast that matters most in practice. The first block is local state, a value owned and changed entirely on the client. The second is server state, data that lives in a database and is only borrowed by the browser. They look superficially similar but have completely different needs, so they get completely different tools.

Counter.tsx

// Local UI state: the client owns it outright.
// No network, no cache, no "is it stale?", just a value and a setter.
import { useState } from "react";

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

  return (
    <button onClick={() => setCount((c) => c + 1)}>
      Clicked {count} times
    </button>
  );
}

useUser.tsx

// Server-cache state: the SERVER owns the truth.
// The library handles caching, loading, errors, and refetching.
import { useQuery } from \"@tanstack/react-query\";

async function fetchUser(id: string) {
  const res = await fetch(`/api/users/${id}`);
  if (!res.ok) throw new Error(\"Failed to load user\");
  return res.json() as Promise<{ id: string; name: string }>;
}

export function useUser(id: string) {
  // We don't store the user in useState or a global store.
  // We describe HOW to fetch it; the cache is managed for us.
  return useQuery({
    queryKey: [\"user\", id],
    queryFn: () => fetchUser(id),
    staleTime: 60_000, // treat as fresh for 60s before refetching
  });
}

// In a component:
//   const { data, isLoading, error } = useUser(userId);
// You get loading + error + cached data for free, no useEffect soup,
// no manual setState, no duplicating the response into a store.

The counter needs nothing but useState. The user needs caching, a loading flag, an error path, and a strategy for staleness, all of which the query library provides. Trying to manage the user with useState + useEffect recreates a worse version of that library by hand; putting the counter in a global store adds machinery a button never asked for.

Server state is not client state

This is the single most clarifying idea in modern frontend, so it gets its own section. Client state is state your app invents and owns: a toggle, a form draft, the current theme. You are the source of truth. Server state is a copy of data that lives somewhere else, a database behind an API. You do not own it; you are borrowing a snapshot.

That difference changes everything. Server state can go stale the moment you fetch it, because someone else might change the record. It needs caching so you do not refetch on every render, refetching so it stays current, and shared loading and error states. None of those concerns exist for client state. This is why purpose-built server-state libraries exist, and why shoving API responses into a general-purpose store is a mismatch: a store has no concept of staleness, background refetch, or request deduplication.

⚠️ The tell-tale sign: If you find yourself writing useEffect to fetch data and then setState to store it, and then more code to track loading and errors, you are hand-rolling a server-state library. Use a real one. It will be less code and far more correct.

Once you split these two, your "global store" usually shrinks to almost nothing. Most of what people pile into Redux is server state that belongs in a query cache. Take that out, and what is left, the genuinely global, client-owned stuff, is often small enough for plain Context or a tiny store.

Common mistakes that cost hours

A global store for everything. Reaching for Redux/Zustand on day one, then routing a dropdown toggle and a form input through it. Every trivial change becomes a four-file edit. Default to local; promote outward only when a real second consumer appears.
Duplicating server data in a store. Fetching a list, copying it into a global store, and then fighting to keep that copy in sync with the server. Now you have two sources of truth and stale-data bugs. Let a server-state library own the cache; read it where you need it.
Prop-drilling instead of composition. Threading a prop through five intermediate components that do not use it, then "fixing" it with global state. Often the real fix is component composition, pass JSX as children so the data-owning parent renders the consumer directly. See Component Architecture & Design Systems.
Context for high-frequency updates. Putting fast-changing values (mouse position, every keystroke) in a single Context re-renders every consumer on every change. Context is for low-frequency, widely-read values like theme or user, not a performance-sensitive firehose.

Takeaways

The whole article in seven lines

State decisions are scope decisions: who reads it, who changes it.
Pick the narrowest scope that works; move outward only when forced.
Five kinds: local UI, lifted/shared, global app, server-cache, URL.
Default to local useState; lifting later is cheap, un-globalizing is not.
Server state is not client state, give it a query library, not a store.
Never duplicate server data into a global store; you create a second truth.
Reach for composition before prop-drilling, and before going global.

Where to go next

State lives inside components, so the cleaner your component boundaries, the more obvious every state decision becomes. Strengthen the layers above and below this one:

Solidify the language underneath it all in JavaScript for the Browser, closures and references are exactly what hooks rely on.
Learn how composition replaces prop-drilling in Component Architecture & Design Systems.
Follow the full Frontend Engineer career path to see where state management sits in the bigger picture.

The next time you feel the urge to install a state library, pause and ask one question: what kind of state is this, and what is the narrowest scope that works? Most of the time, the answer is useState, and that is a feature, not a shortcoming.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.

Rendering Strategies: CSR, SSR, SSG & ISR

Sri Balaji — Sun, 11 Oct 2026 16:28:16 +0000

⚡ TL;DR: Where your HTML is built, in the browser, on the server, or at build time, decides first paint, SEO, server cost, and complexity. Match CSR, SSR, SSG, or ISR to the page, and respect hydration, the cost everyone underestimates.

The beautiful app nobody could find
One sentence, then a kitchen
Where the HTML actually comes from
The four strategies, side by side
What this looks like in config
Hydration: the part everyone underestimates
Common mistakes that cost you users
Takeaways
Where to go next

The beautiful app nobody could find

You build a gorgeous single-page app. Smooth transitions, instant client-side routing, a design the team is proud of. You ship it. Then two things happen. First, you search for it on Google and the result is a blank page with a title, because the crawler saw an empty <div id="root"> and a pile of JavaScript it never ran. Second, a colleague opens it on a mid-range phone over 4G and stares at a white screen for four seconds while a 600 KB bundle downloads, parses, and finally paints the UI.

Nothing is broken. The code is fine. The problem is where the HTML got built. Your app decided to build it in the browser, at the worst possible moment, on the slowest device. That decision, the rendering strategy, is one of the highest-leverage choices in frontend, and most people make it by accident.

📌 Who this is for: Frontend developers who've shipped a React/Vue/Angular app and heard "SSR", "SSG", "hydration", and "ISR" thrown around without a clear map. By the end you'll know exactly where your HTML is produced for each strategy, what each one costs, and how to pick. No framework lock-in, the ideas apply everywhere.

One sentence, then a kitchen

A rendering strategy is just the answer to one question: where and when is the HTML for this page built, in the browser, on the server per request, or once at build time?

The whole article in a sentence

Think of your HTML like food at a restaurant. The same dish can reach the customer three different ways, and each has a real trade-off between freshness, speed, and cost.

In the real world	In tech
Cook-to-order: the chef makes your dish fresh when you order. Always current, but you wait, and the kitchen works on every order.	SSR, the server renders HTML on each request. Fresh data, slower first byte, work per visit.
Pre-made on the shelf: cooked once this morning, grabbed instantly. Lightning fast, but it's as fresh as this morning.	SSG, HTML built once at deploy time, served from a CDN. Instant, but stale until you rebuild.
Meal-prep that refreshes on a timer: a batch sits ready, and a fresh batch is quietly made every hour.	ISR, static pages that regenerate in the background on an interval. Fast like static, fresher than static.
Cook it yourself at the table: the kitchen hands you raw ingredients and a stove.	CSR, the browser receives an empty shell plus JS and assembles the page itself.

Same meal, three kitchens, that's the entire rendering debate.

Where the HTML actually comes from

Every strategy answers the same request differently. Here's the same page request flowing to four different producers, then arriving at the browser where, for the JS-driven ones, it gets hydrated into a live app.

One request, four places the HTML can be built, then hydration wires it up in the browser.

The request arrives: A user clicks a link or types a URL. The same starting point for all four strategies, what differs is who answers.
Someone produces HTML: CSR ships a near-empty shell and lets the browser build the DOM from JS. SSR runs your components on the server right now. SSG/ISR hand back HTML that was rendered earlier, at build time, or refreshed in the background.
First paint happens: The moment usable HTML hits the screen. For SSR/SSG/ISR this is fast and content-rich. For CSR it waits until the JS bundle downloads and runs.
Hydration makes it interactive: For any JS framework, the server-rendered HTML is static until the client JS loads, walks the DOM, and attaches event handlers. Until hydration finishes, buttons look ready but don't respond.

The four strategies, side by side

This table is the one you'll come back to. Read it as four levers, first paint, SEO, server cost, and freshness, that you can't all max at once.

	First paint	SEO	Server cost	Data freshness
CSR	Slow (waits for JS)	Weak by default	Cheapest (static host)	Live (fetches on load)
SSR	Fast (HTML ready)	Strong	Highest (work per request)	Live (per request)
SSG	Fastest (CDN)	Strong	Near zero (just files)	Stale until rebuild
ISR	Fastest (CDN)	Strong	Low (occasional regen)	Near-fresh (timed/on-demand)

The core trade-off: nobody wins every column.

A useful read: SSG and ISR look identical to the visitor, both serve a prebuilt file from a CDN. The difference is purely on your side: SSG only updates when you redeploy, while ISR refreshes itself on a schedule or when triggered. SSR is the only one paying compute on every single visit, which is exactly why "just SSR everything" gets expensive.

What this looks like in config

You rarely hand-build these. In a framework like Next.js, the strategy is often one line, whether a fetch is cached, and whether it revalidates. The mental model maps straight onto the config.

app/products/[id]/page.tsx

// SSG, fetched once at build, served forever (until next deploy)
async function getStatic(id: string) {
  const res = await fetch(`/api/products/${id}`, { cache: "force-cache" });
  return res.json();
}

// ISR, static, but regenerate in the background at most every 60s
async function getIsr(id: string) {
  const res = await fetch(`/api/products/${id}`, { next: { revalidate: 60 } });
  return res.json();
}

// SSR, render fresh on every request, never cache
async function getSsr(id: string) {
  const res = await fetch(`/api/products/${id}`, { cache: "no-store" });
  return res.json();
}

💡 Tip: Notice there's no CSR line here, CSR is what you get when you fetch inside a client component with useEffect instead of in a server-rendered function. The choice of where you fetch quietly decides your rendering strategy.

Hydration: the part everyone underestimates

Server-rendered HTML (SSR, SSG, ISR) reaches the browser as dead markup, it looks right, but no click does anything yet. Hydration is the process where the client framework downloads, re-runs your components, walks the existing DOM, and attaches event listeners so the page becomes interactive.

This creates a sneaky gap. Your content paints fast (great!), but there's a window where the page looks interactive and isn't. A user taps a menu, nothing happens, they tap again, and now two clicks fire once hydration lands. The bigger your JS bundle, the longer that dead window, which is why "server-rendered" alone doesn't guarantee a fast-feeling app.

The modern answer is to hydrate less. React Server Components and similar approaches split your tree: components that are purely presentational render on the server and ship as plain HTML with zero client JS, while only the genuinely interactive bits (a search box, a cart button) ship and hydrate. This hybrid model keeps the fast first paint of static rendering while shrinking the hydration cost that used to come bundled with it.

Server Components, run on the server, send HTML, ship no JS to the client. Use for layout, content, data display.
Client Components, ship JS and hydrate. Use only where you need state, effects, or event handlers.
The win, you pay hydration cost only for the interactive islands, not the whole page.

Common mistakes that cost you users

CSR for a content or marketing site. Blogs, docs, landing pages, e-commerce listings, anything that lives or dies by search traffic, should never be pure client-rendered. Crawlers and social previews see an empty shell, and your first paint is gated on a bundle. Pick SSG or ISR.
Ignoring hydration cost. Shipping a 500 KB bundle and assuming SSR "made it fast", the HTML paints quickly but the page is dead until hydration finishes. Measure interactivity (INP / Total Blocking Time), not just first paint, and cut the bundle.
SSR-ing everything. Rendering every page per request when 90% of it is identical for every user burns server compute and adds latency you didn't need. If the data doesn't change per request, it should be SSG or ISR, not SSR.
Forgetting freshness with SSG. Pure static means stale until redeploy. If prices, inventory, or article edits need to show up within minutes, reach for ISR's revalidate instead of triggering a full rebuild for every change.
Treating it as one global setting. Modern frameworks let you choose per route. Your marketing pages can be SSG, your dashboard SSR, your product pages ISR, in the same app. Don't pick one strategy for everything.

Takeaways

The whole article in seven lines

A rendering strategy is just where and when your HTML is built.
CSR builds in the browser, cheap to host, weak SEO, slow first paint.
SSR builds on the server per request, fresh and SEO-strong, but pays compute every visit.
SSG builds once at deploy, fastest and cheapest, but stale until you rebuild.
ISR is SSG that refreshes itself on a timer, static speed, near-fresh data.
Hydration is the gap between "looks ready" and "actually responds", measure it, shrink the bundle.
The modern hybrid (Server Components) ships HTML for most of the page and hydrates only the interactive islands. Choose per route, not per app.

Where to go next

Rendering strategy decides where the HTML is built, but to reason about why first paint and hydration feel the way they do, you need to understand what the browser does with that HTML once it arrives, and how to measure the result.

How the Browser Renders a Page, the parse → layout → paint pipeline that turns your HTML into pixels.
Core Web Vitals & Frontend Performance, how to measure LCP, INP, and CLS so you can prove a strategy change actually helped.
Follow the full Frontend Engineer path to put rendering, performance, and architecture together.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.

JavaScript for the Browser

Sri Balaji — Sat, 10 Oct 2026 16:03:33 +0000

⚡ TL;DR: Internalize the single-threaded event loop and the sync, microtask, macrotask ordering it enforces. That one model explains promises, event delegation, and why a long task freezes your UI, plus how to avoid blocking paint.

The click that froze a page
One chef, one thread
The picture: how the event loop works
Ordering: sync vs microtask vs macrotask
Events, delegation, and async in real code
Why long tasks block paint
Common mistakes that cost hours
Takeaways
Where to go next

The click that froze a page

You wire up a button. On click, it filters a list of 50,000 rows in a tight loop and re-renders. In testing it felt fine. In production a user clicks it and the entire page locks up, the spinner stops spinning, hover states stick, other buttons do nothing, even the browser's own tab feels dead. For two whole seconds nothing responds. Then it snaps back to life as if nothing happened.

Nothing crashed. No error in the console. The page wasn't "slow" in the network sense, the work was already done locally. So what happened? The answer is the single most important thing a frontend engineer can understand: JavaScript in the browser runs on one thread, and while your code runs, nothing else can. Not animation, not clicks, not paint. Once you internalize the runtime model, async stops being magic and bugs like this become obvious.

📌 Who this is for: Frontend engineers who can write JavaScript but get surprised by async ordering, frozen UIs, or memory leaks from event listeners. If you've ever wondered why a setTimeout(fn, 0) doesn't run immediately, or why a Promise resolves "before" a timer, this is for you. No prior knowledge of the event loop assumed.

One chef, one thread

JavaScript in the browser is a single-threaded runtime: one call stack, doing one thing at a time. "Async" doesn't mean parallel, it means "do this later, when I'm free."

The cleanest mental model is a kitchen with exactly one chef. The chef can only do one task at a time. They have two notebooks. The first is a regular to-do list (tasks): "chop onions," "plate dish 4." The second is a priority list (microtasks): small urgent notes the chef promises to clear before starting the next to-do item.

In the real world	In tech
The single chef	The one JavaScript thread (the call stack)
The dish the chef is cooking right now	The function currently on the call stack
Sous-chefs handling the oven & deliveries	Web APIs (timers, fetch, DOM events), run off-thread
The regular to-do list	The task (macrotask) queue, clicks, timers
The urgent priority list, cleared first	The microtask queue, promise callbacks
The chef checking lists when hands are free	The event loop

The kitchen maps directly onto the JavaScript runtime.

The crucial rule: the chef finishes the current dish completely before looking at either list. They never abandon a half-plated dish to answer the door. That "run to completion" rule is exactly why a long task freezes everything, and why ordering between timers and promises is so precise.

The picture: how the event loop works

Here is the whole runtime in one diagram. Your synchronous code runs on the call stack. Anything async (a timer, a fetch, a click listener) is handed to Web APIs, which run outside the thread and, when done, drop a callback into a queue. The event loop is the part that, whenever the stack is empty, drains the microtask queue fully, then takes one macrotask, then repeats.

The browser JavaScript runtime: stack ↔ Web APIs → queues → event loop → back to the stack.

User clicks a button: The browser's event system (a Web API) registers the click and queues your handler as a macrotask. Your currently-running code, if any, is not interrupted.
The stack empties: Whatever was running finishes and returns. The call stack is now empty, the event loop's signal that it may pick up new work.
Microtasks drain first: Before touching the click, the loop empties the entire microtask queue, every pending promise .then/await continuation runs to completion (and any microtasks they schedule run too).
One macrotask runs: Now the loop takes exactly one task, your click handler, and pushes it onto the stack. It runs to completion, start to finish, uninterrupted.
Render gets a turn: Only after the handler returns and microtasks are drained can the browser repaint. Then the loop comes back for the next macrotask.

Ordering: sync vs microtask vs macrotask

This is the table to memorize. Given this code, console.log("A"); setTimeout(() => console.log("D"), 0); Promise.resolve().then(() => console.log("C")); console.log("B");, the output is A, B, C, D. Synchronous lines run first, then all microtasks (the promise), then the macrotask (the timer), even though the timer was scheduled with 0.

Tier	Examples	When it runs	Output
Synchronous	top-level code, function bodies	Right now, on the stack, in order	A, then B
Microtask	`Promise.then`, `await` continuation, `queueMicrotask`	After the stack empties, ALL of them, before any macrotask	C
Macrotask	`setTimeout`, `setInterval`, click/DOM events, `fetch` callback dispatch	One per loop turn, after microtasks drain	D

Why A, B, C, D and not A, B, D, C, three priority tiers, drained in order.

⚠️ setTimeout(fn, 0) is not immediate: The 0 is a minimum delay, not a guarantee. The callback is a macrotask, so it waits behind every pending microtask and behind the browser's own work. A Promise.resolve().then(...) scheduled after it will still run first.

Events, delegation, and async in real code

Two patterns cover most real frontend work: event delegation (one listener on a parent instead of one per child, leaning on event bubbling) and async/await for network calls. Here both are in a small, complete example, a list where clicking any item fetches its detail.

list.js

// ONE listener on the container, not one per <li>.
// Clicks on children bubble up to here, that's delegation.
const list = document.querySelector("#items");

list.addEventListener("click", async (event) => {
  // event.target is the actual clicked node; find the row it lives in.
  const item = event.target.closest("li[data-id]");
  if (!item) return; // clicked the gap between items, ignore.

  item.classList.add("loading");
  try {
    // await yields the thread back to the event loop while the
    // network request runs off-thread in a Web API.
    const res = await fetch(\`/api/items/\${item.dataset.id}\`);
    if (!res.ok) throw new Error(\`HTTP \${res.status}\`);
    const data = await res.json();

    // DOM manipulation: build a node, then attach it.
    const detail = document.createElement("p");
    detail.textContent = data.description;
    item.appendChild(detail);
  } catch (err) {
    item.textContent = "Failed to load, tap to retry.";
    console.error(err);
  } finally {
    item.classList.remove("loading");
  }
});

Why delegation wins: it works for rows added after the listener was attached (no rebinding), it uses one listener instead of thousands, and there's nothing to clean up per row. The await lines are where the thread is handed back, between them the browser is free to paint and handle other clicks. That's cooperative async on a single thread.

Why long tasks block paint

Now the frozen page makes sense. Rendering, style, layout, paint, is also work the one thread must do, scheduled between macrotasks. The browser wants to repaint roughly every 16ms (60fps). But it can only do that when the call stack is empty. While your filter-50,000-rows handler runs, the stack is never empty, so the loop never gets a turn, so no paint, no clicks, no animation. The thread is busy and there is only one.

A task that runs longer than ~50ms is officially a "long task", long enough that users perceive jank. The fix is never "make it async" by sprinkling promises (microtasks run on the same thread and still block paint). The fix is to break the work up, yield to the event loop between chunks (e.g. await scheduler.yield() or chunk across setTimeout/requestIdleCallback), or move the heavy computation off-thread entirely with a Web Worker, which is a genuinely separate thread.

💡 Tip: Quick test: if await Promise.resolve() in the middle of your loop does NOT unfreeze the UI, the work is CPU-bound and belongs in a Web Worker or needs to be chunked with a macrotask that lets paint in between. Microtasks alone won't save you.

Common mistakes that cost hours

Blocking the main thread. Heavy loops, giant JSON parses, or synchronous layout reads in a handler freeze everything. Chunk the work, defer it, or offload to a Web Worker.
Leaking listeners. Every addEventListener you never remove keeps its closure, and the DOM nodes it references, alive. In SPAs that re-mount components, this is the classic memory leak. Remove listeners on teardown, or use delegation so there's only one.
Not delegating. Attaching a listener to every item in a list is slower to set up, breaks for dynamically-added items, and multiplies cleanup. One listener on the parent + event.target.closest() is almost always better.
await inside a loop. for (const id of ids) { await fetch(id); } runs requests strictly one after another. If they're independent, fire them together with await Promise.all(ids.map(fetch)), same thread, but the waiting overlaps instead of stacking.

Takeaways

The whole article in seven lines

Browser JavaScript is single-threaded: one call stack, one thing at a time.
Async work is offloaded to Web APIs; their callbacks return via queues.
The event loop drains ALL microtasks, then takes ONE macrotask, then lets the page paint.
Order is sync → microtasks (promises) → macrotasks (setTimeout, events).
setTimeout(fn, 0) is a macrotask, it waits behind every pending promise.
A handler runs to completion; while it runs, no paint, no clicks, that's why long tasks freeze the UI.
Delegate events to a parent, clean up listeners, and chunk or offload CPU-heavy work.

Where to go next

Once the runtime model clicks, the rest of frontend engineering layers cleanly on top. Two natural next reads: understanding what the browser does after your handler returns, and how to manage the data your handlers produce without re-introducing the chaos manual DOM updates create.

How the Browser Renders a Page, what happens in that paint slot the event loop hands the browser: style, layout, and compositing.
State Management in Frontend Apps, once DOM updates get complex, move state out of the DOM and let a framework re-render for you.
Follow the full Frontend Engineer path to see where the runtime, rendering, and frameworks fit together.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.

CSS Fundamentals: The Box Model & Layout

Sri Balaji — Fri, 09 Oct 2026 17:15:26 +0000

⚡ TL;DR: CSS stops fighting you once the box model, the cascade, and normal flow click. The practical payoff: reach for Flexbox for one dimension and Grid for two, and finally know why that div would not center.

Why won't this div center?
Every element is a box
The box model, layer by layer
Normal flow: what happens before you do anything
Flexbox vs Grid: one dimension or two
Build it: a responsive layout
The cascade & specificity
Common mistakes that cost hours
Takeaways
Where to go next

Why won't this div center?

Every developer has lived this moment. You have a box. You want it in the middle of the screen. You try margin: auto. Nothing. You try text-align: center. The text moves, the box doesn't. You add padding, and now the box is bigger instead of centered. Twenty minutes later you are googling "how to center a div" for the fortieth time in your career, half-convinced CSS is broken.

CSS is not broken. It is doing exactly what you told it to, you just don't yet have the mental model for what "it" is. Once you internalize four ideas, the box model, the cascade, normal flow, and modern layout (Flexbox and Grid), CSS stops feeling like a slot machine and starts feeling like a language. This article installs those four models.

📌 Who this is for: Anyone who can write a little HTML and CSS but feels like layout "just happens to" them rather than something they control. If you've ever pasted a display: flex from Stack Overflow without knowing why it worked, this is for you. No build tools, no framework, just CSS and a browser.

Every element is a box

In CSS, everything is a rectangular box, and layout is just the art of sizing those boxes and arranging them relative to each other.

The one sentence that unlocks CSS

That <h1>, that <p>, that <button>, even an inline <span>, the browser draws each one as a box. And each box is built in layers, like a parcel ready for shipping. Picture mailing a fragile mug:

In the real world	In tech
The mug itself	content, your text or image
Bubble wrap snug around the mug	padding, space inside the box, around the content
The cardboard box walls	border, the visible edge of the box
Empty space between this parcel and the next on the shelf	margin, space outside the box, pushing neighbours away

Content out, padding hugs it, border wraps it, margin keeps the neighbours at arm's length.

Padding is inside the box and shares its background colour. Margin is outside and is always transparent. Get those two confused and you will spend hours wondering why a background colour bleeds where you didn't expect it, almost always a padding-vs-margin mix-up.

The box model, layer by layer

The four nested layers of every CSS box, from the content out to the margin.

Read it from the inside out. To find how much horizontal room an element actually takes on screen by default, you add it all up. Here is the walkthrough for a box declared width: 200px:

Start with the content width: You wrote width: 200px. By default that 200px applies to the content box only, the mug, not the packaging.
Add padding to both sides: padding: 20px adds 20px left + 20px right = 40px. The box is now 240px wide on screen.
Add the border to both sides: border: 5px solid adds 5px left + 5px right = 10px. Now 250px.
Margin pushes neighbours, not the box: margin: 10px doesn't change the box's own width, it reserves 10px of empty space outside it. The rendered box stays 250px; its neighbours just keep their distance.
Feel the surprise: You asked for 200px and got a 250px box. This off-by-padding-and-border math is the #1 reason CSS layouts overflow, and box-sizing (next section) makes it vanish.

Normal flow: what happens before you do anything

Before any flex or grid, the browser already lays elements out using normal flow. The two rules worth memorizing: block elements (<div>, <p>, <h1>) stack vertically and take the full available width. Inline elements (<span>, <a>, <strong>) sit side by side on a line and only take as much width as their content.

This is why width on a <span> seems to do nothing (inline boxes ignore it) and why two <div>s never sit beside each other on their own (block boxes claim the whole row). For years, developers fought this with float to force side-by-side layout. Don't, floats were designed for wrapping text around images, not for page layout. Flexbox and Grid are the modern, purpose-built tools.

Flexbox vs Grid: one dimension or two

Both Flexbox and Grid are layout systems you switch a container into. The single question that tells you which to use: am I laying things out along one line, or in a grid of rows and columns?

	Flexbox	Grid
Dimensions	One at a time (a row OR a column)	Two at once (rows AND columns)
Mental model	Distribute items along a single axis	Place items into a defined grid of cells
Sizing driven by	Mostly the content itself	Mostly the container's defined tracks
Best for	Navbars, toolbars, button rows, centering one thing, card internals	Page layouts, image galleries, dashboards, anything with aligned rows + columns
Turn it on	`display: flex` on the parent	`display: grid` on the parent
Rule of thumb	Content arranged in a line → Flexbox	Layout with a defined structure → Grid

Reach for Flexbox for content arranged in a line; reach for Grid for a true 2D structure.

💡 They are friends, not rivals: Real pages use both: Grid for the overall page skeleton (header / sidebar / main / footer), Flexbox inside each region to line up its contents. You don't pick one for the whole app, you pick the right one per container.

Build it: a responsive layout

Here is a small but real layout: a centered hero, then a card grid that reflows from three columns to one on narrow screens. Note the very first rule, set box-sizing: border-box globally so width finally means the total width, padding and border included. This one line ends the box-model surprise forever.

layout.css

/* 1. Make width mean total width, everywhere */
*,
*::before,
*::after {
  box-sizing: border-box;
}

/* 2. Flexbox: center one thing on both axes */
.hero {
  display: flex;
  justify-content: center; /* main axis: horizontal */
  align-items: center;     /* cross axis: vertical   */
  min-height: 60vh;
  text-align: center;
}

/* 3. Grid: a responsive card layout, no media query needed */
.cards {
  display: grid;
  /* as many 240px+ columns as fit; they share leftover space */
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  gap: 1.5rem;
  padding: 2rem;
}

.card {
  /* width:100% now includes padding + border, no overflow */
  width: 100%;
  padding: 1.5rem;
  border: 1px solid #e5e7eb;
  border-radius: 0.75rem;
}

/* 4. Flexbox again, inside each card, to stack + space its parts */
.card {
  display: flex;
  flex-direction: column;
  gap: 0.75rem;
}

The classic "center a div" problem? Solved in three lines: display: flex; justify-content: center; align-items: center; on the parent. No magic margins, no negative offsets. And the card grid is fully responsive with zero media queries, auto-fit plus minmax lets the browser decide how many columns fit. That is the modern toolset doing the work you used to do by hand.

The cascade & specificity

The C in CSS is Cascading. When two rules target the same element and disagree, the browser needs a tiebreaker. It resolves conflicts in this order: importance, then specificity, then source order.

Importance, an !important declaration beats a normal one. (Use this almost never; see the mistakes below.)
Specificity, a score based on the selector. Inline style="" beats an #id beats a .class beats a plain tag. Roughly: ids are worth more than classes, classes more than tags.
Source order, if specificity ties, the rule written last wins. This is why the order of your stylesheet matters.

A concrete tiebreak: a .btn rule and a button rule both set colour. The .btn class wins because a class outranks a tag, regardless of which one you wrote first. Most "my CSS isn't applying!" moments are a more specific rule quietly overriding yours. The fix is almost never !important, it's understanding which selector is winning and matching or beating it cleanly.

⚠️ Keep specificity low and flat: Prefer single classes (.card-title) over deep chains (section.content div.card h2.title). Flat, low-specificity selectors are easy to override later. Deep, high-specificity ones start a war that ends in !important, and a stylesheet nobody can safely change.

Common mistakes that cost hours

No box-sizing: border-box. Without it, adding padding makes elements wider than the width you set, so they overflow their container. Set it globally once (as in the code above) and never think about box-model math again.
Fighting specificity with !important. It feels like a fix; it's a debt. Now the only way to override that rule is another !important, and you've started an arms race. Lower your selector specificity instead, !important should be a last resort, not a habit.
Using float for layout. Floats were built to wrap text around images. Using them to put boxes side by side leads to collapsed parents, clearfix hacks, and fragile layouts. Use Flexbox or Grid, they were designed for exactly this.
Confusing padding and margin. Padding adds space inside (and inherits the background); margin adds space outside (always transparent). Reaching for the wrong one is why backgrounds bleed or gaps refuse to appear where you want them.
Vertical margins that mysteriously collapse. Adjacent top/bottom margins merge into the larger of the two rather than adding up. If a gap is half what you expected, margin collapsing is the usual suspect, gap inside a flex/grid container sidesteps it entirely.

Takeaways

The whole article in seven lines

Every element is a box: content → padding → border → margin, nested like a parcel.
Set box-sizing: border-box globally so width means the total width, this kills the #1 layout bug.
Padding is inside (inherits background); margin is outside (always transparent).
Normal flow is the default: block elements stack, inline elements sit in a line.
Flexbox = one dimension (a row or a column). Grid = two dimensions (rows and columns). Use both, per container.
The cascade resolves conflicts by importance → specificity → source order; keep specificity low and flat.
Avoid !important and floats-for-layout, they're the debts that cost you hours later.

Where to go next

You now have the four mental models that make CSS predictable. The natural next steps are understanding why the browser draws these boxes the way it does, and then how to organize CSS once a project grows past a single file.

Read How the Browser Renders a Page to see how the DOM, CSSOM, layout, and paint turn your boxes into pixels, and why some CSS changes are far cheaper than others.
Read Component Architecture & Design Systems for how to keep specificity low and styles reusable as your app scales beyond one stylesheet.
Follow the full Frontend Engineer path for the foundation-to-senior track these articles belong to.
Practice deliberately: rebuild a layout you admire using only Grid for the page skeleton and Flexbox inside each region. Nothing cements these models faster than shipping one real layout.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.

How the Browser Renders a Page

Sri Balaji — Thu, 08 Oct 2026 17:40:11 +0000

⚡ TL;DR: Trace HTML bytes to pixels through the critical rendering path: DOM, CSSOM, layout, paint, composite. Once you know what blocks rendering and why reflows are expensive, you can stop layout thrashing and fix the real performance killers.

You hit Enter, then what?
One sentence, then a picture
The critical rendering path
What happens at each stage, and what slows it down
What blocks rendering
Reflow vs repaint vs composite (and layout thrashing)
Common mistakes that cost hours
Takeaways
Where to go next

You hit Enter, then what?

You type a URL, hit Enter, and a fraction of a second later a fully styled page appears. It feels like one instant event. It isn't. Between the server sending back a blob of text and you seeing pixels, the browser runs a precise assembly line called the critical rendering path. Every stage depends on the one before it, and any stage can stall the whole pipeline.

Most performance problems, janky scrolling, a button that lags when you click it, a page that sits blank for a beat too long, are really just one of these stages doing more work than it should. Once you can name the stages, you can name the bug.

📌 Who this is for: Frontend developers who can write HTML, CSS, and JavaScript but have never looked under the hood at how they become pixels. No prior browser-internals knowledge needed. If you have ever wondered why "just adding a class" can cause a stutter, this is for you.

One sentence, then a picture

Rendering is the process of turning your HTML and CSS into a tree the browser understands, working out where everything goes, and then drawing it, in that order, every time.

Think of it like assembling flat-pack furniture. The HTML is the instruction booklet that lists every part and how they nest together. The CSS is the parts list that says which panel is which colour, which screw is which size. You cannot start screwing things together until you have read both the instructions and checked the parts. Only then can you lay the pieces out on the floor (layout), paint or stain them (paint), and finally slot the finished sections into place to form the wardrobe (composite).

In the real world	In tech
The instruction booklet (how parts nest)	HTML parsed into the DOM tree
The parts list (which panel, which colour)	CSS parsed into the CSSOM tree
Reading instructions + parts together	DOM + CSSOM merged into the render tree
Laying pieces out on the floor	Layout, computing position and size
Painting and staining each piece	Paint, filling in pixels, colours, shadows
Slotting finished sections together	Composite, stacking layers into the final frame

Building a page is building flat-pack furniture.

The critical rendering path

Here is the whole pipeline. Bytes come in on the left; pixels come out on the right. The browser never skips a step, and it processes them strictly left to right.

The critical rendering path: from source files to pixels on screen.

HTML → DOM: The browser reads the HTML bytes, decodes them into characters, tokenizes the tags, and builds the Document Object Model, a tree of nodes where every element, attribute, and text node is an object you can read and change from JavaScript.
CSS → CSSOM: In parallel, every stylesheet (external, internal, and inline) is parsed into the CSS Object Model, a tree of style rules. Like the DOM, it is a tree, because styles cascade and inherit down from parents to children.
DOM + CSSOM → Render Tree: The two trees are merged. The render tree contains only what will actually be drawn: nodes with display: none are dropped entirely, and each remaining node carries its computed styles. <head>, <script>, and hidden elements never make it in.
Layout (a.k.a. reflow): The browser walks the render tree and calculates the exact geometry of every node, its width, height, and x/y position on the page. This is where percentages, flexbox, and grid get resolved into real pixel boxes.
Paint: With geometry known, the browser fills in the actual pixels: text glyphs, colours, borders, shadows, gradients, images. The output is a set of draw commands, often split across several layers.
Composite: Finally the painted layers are stacked in the right order, respecting z-index, transforms, and opacity, and handed to the GPU to assemble the single frame you see. Smooth animations live here.

What happens at each stage, and what slows it down

Each stage has its own cost profile. Knowing which stage your change touches tells you how expensive it will be. Here is the cheat sheet.

Stage	What happens	What makes it slow
DOM build	HTML parsed into a node tree	Huge or deeply nested markup; thousands of elements
CSSOM build	Stylesheets parsed into style rules	Large CSS files; complex, deeply nested selectors
Render tree	Visible DOM nodes get computed styles	Mostly proportional to DOM + CSSOM size
Layout	Geometry of every box computed	Touching layout-affecting properties; large DOM; reading layout mid-write
Paint	Pixels filled per layer	Large paint areas; expensive effects (shadows, blur, gradients)
Composite	Layers stacked on the GPU	Too many layers; very large layers eating GPU memory

The six stages, what they do, and what makes them slow.

What blocks rendering

Two resource types can freeze the pipeline: CSS and JavaScript. CSS is render-blocking by default, the browser will not build the render tree (and therefore will not paint) until it has the CSSOM, because painting with the wrong styles would cause an ugly flash. JavaScript is parser-blocking: a plain <script> stops HTML parsing dead while it downloads and executes, because the script might call document.write or read the DOM.

index.html

<!-- BLOCKS: parser stops here until app.js downloads AND runs -->
<script src="/app.js"></script>

<!-- BETTER: download in parallel, run after HTML is parsed -->
<script src="/app.js" defer></script>

<!-- For independent scripts (analytics): run whenever ready -->
<script src="/analytics.js" async></script>

<!-- CSS is render-blocking: the page won't paint until this loads -->
<link rel="stylesheet" href="/styles.css" />

defer, download the script in the background while parsing continues, then execute it in order, just before DOMContentLoaded. The right default for app code.
async, download in the background, then execute the moment it arrives, interrupting parsing. Good for independent third-party scripts that do not touch your DOM.
No attribute, fully blocking. Avoid in <head> unless the script genuinely must run before the page is parsed.

💡 Why CSS in the is still correct: It is tempting to think render-blocking CSS is bad, so move it down. Do not. You want CSS discovered early so the CSSOM is ready by the time the DOM is. Instead, keep the critical CSS small and load non-essential styles separately. Block early on a little, not late on a lot.

Reflow vs repaint vs composite (and layout thrashing)

After the first render, the page is not frozen, JavaScript and user interaction keep changing it. The cost of a change depends on how far back up the pipeline it forces the browser to go. This is the single most useful performance idea in this whole article.

Reflow (layout) is the most expensive. Change something geometric, width, height, top, font-size, adding a DOM node, and the browser must recompute geometry, then repaint, then composite. The whole tail of the pipeline reruns.
Repaint is cheaper. Change only appearance, color, background, box-shadow, visibility, and geometry is untouched, so the browser skips layout but still repaints and composites.
Composite-only is cheapest. Animate transform or opacity and the browser can skip both layout and paint, just re-stacking existing layers on the GPU. This is why smooth 60fps animations stick to transform and opacity.

Layout thrashing is the classic trap. The browser is smart enough to batch your style writes and reflow once, unless you read a layout value in between. Reading something like offsetHeight forces the browser to flush all pending changes and reflow right now so it can give you an accurate answer. Do that inside a loop and you force a reflow on every single iteration.

thrash.js

// ❌ Layout thrashing: read -> write -> read -> write...
// Each offsetWidth read forces a synchronous reflow.
for (const box of boxes) {
  const w = box.offsetWidth;       // READ (forces reflow)
  box.style.width = w + 10 + "px"; // WRITE (invalidates layout)
}

// ✅ Batch: read everything first, then write everything.
const widths = boxes.map((box) => box.offsetWidth); // all READS
boxes.forEach((box, i) => {
  box.style.width = widths[i] + 10 + "px";          // all WRITES
});

Common mistakes that cost hours

Render-blocking scripts in <head>. A plain <script src> before your content stalls parsing and delays first paint. Add defer, or move it to the end of <body>.
Layout thrashing in loops. Interleaving DOM reads (offsetTop, getBoundingClientRect) and writes forces a reflow per iteration. Batch all reads, then all writes.
Animating layout properties. Animating width, top, or margin reflows every frame and drops your frame rate. Animate transform and opacity instead.
A huge DOM. Tens of thousands of nodes make every reflow and style recalculation slow. Virtualize long lists and prune unnecessary wrapper elements.
One giant CSS file. All of it is render-blocking. Ship the critical styles inline or small, and defer the rest so first paint is not held hostage.

Takeaways

The whole article in six lines

The browser runs a fixed pipeline: HTML→DOM, CSS→CSSOM, render tree, layout, paint, composite.
CSS is render-blocking; plain scripts are parser-blocking. Use defer for app code, async for independent scripts.
Reflow (layout) is the most expensive change, repaint is cheaper, composite-only is cheapest.
Animate transform and opacity to stay on the cheap composite-only path.
Layout thrashing, reading a layout value between writes, forces a reflow per read. Batch reads, then writes.
Most jank is one stage doing too much work. Name the stage, fix the bug.

Where to go next

Now that you can see the pipeline, the next step is measuring it on real pages and understanding the layout model that feeds the layout stage.

Core Web Vitals & Frontend Performance, turn this mental model into the metrics Google actually measures.
CSS Fundamentals: The Box Model and Layout, master the box model that the layout stage resolves into pixels.
Follow the full Frontend Engineer path to build on these foundations step by step.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.

What Is a Frontend Engineer?

Sri Balaji — Wed, 07 Oct 2026 17:37:03 +0000

⚡ TL;DR: Frontend engineering is far more than styling: it owns the browser runtime, interaction, and the human-facing layer. The takeaway is a clear map of what the role actually owns versus the backend, and the modern skills it really demands.

You can see the work, and that is the hard part
A one-line definition (and a kitchen)
The browser is the runtime
Frontend vs backend: who owns what
The modern skill set (beyond "just styling")
Common misconceptions
Takeaways
Where to go next

You can see the work, and that is the hard part

Open any app you used today. The login screen, the menu that slides in, the spinner while a page loads, the form that turns red when you mistype your email, every pixel a human looks at or touches was built by a frontend engineer. And because everyone can see it, everyone has an opinion on it. That is the strange pressure of the role: your work is the most visible thing in the entire company, and the least forgiving.

The catch is that what users see is the smallest part of the job. Making a button look right is an afternoon. Making it stay usable across phones and laptops, load fast on a slow train, work for someone using a screen reader, and not break when the server returns an error, that is the actual craft. People hear "frontend" and think "styling." The reality is closer to engineering a live application that runs on a machine you do not control: the user's browser.

📌 Who this is for: Anyone curious about what a frontend engineer actually does, career switchers, students, backend devs eyeing the other side, or hiring managers writing a job spec. No coding experience assumed. By the end you will know what the role owns, where it stops, and the skills that separate a junior from a senior.

A one-line definition (and a kitchen)

A frontend engineer builds the user-facing layer of an application, the interface that runs inside the browser, using HTML, CSS, JavaScript, and frameworks, and connects it to backend services over the network.

Working definition

That sentence is dense, so picture a restaurant instead. The kitchen is the backend: the chefs, the inventory, the recipes, the food safety rules. Customers never see it, and that is the point, it is where the real cooking, storage, and logic happen.

The dining room and front-of-house is the frontend. It is the menu you read, the table layout, the lighting, the waiter who takes your order and brings it back. The front-of-house does not grow the vegetables, but if the menu is confusing, the lighting is harsh, or the waiter forgets your order, you have a bad night no matter how good the kitchen is. The frontend engineer designs and runs that dining room: every interaction between the human and the system passes through it.

In the real world	In tech
The dining room you sit in	The UI rendered in the browser
The menu you read and choose from	HTML, the content and structure
Lighting, table layout, decor	CSS, the visual styling and layout
The waiter taking and relaying your order	JavaScript, the behaviour and interactions
The kitchen cooking and storing food	The backend: servers, databases, business logic
The waiter walking orders to the kitchen	API calls over the network

The restaurant maps almost one-to-one onto how a web app is built.

The browser is the runtime

Here is the idea that reframes everything: the frontend engineer does not control the computer the code runs on. A backend engineer deploys to servers they configure. The frontend ships code to the user's browser, Chrome, Safari, Firefox, on a flagship phone or a five-year-old budget Android, and that browser is the runtime. It downloads three kinds of files and assembles a living interface out of them.

HTML is the structure, the headings, paragraphs, buttons, and inputs. It is the skeleton and the content.
CSS is the presentation, colors, spacing, fonts, and how the layout reflows from a wide laptop to a narrow phone.
JavaScript is the behaviour, what happens when you click, type, or scroll, and how the page fetches fresh data without a full reload.

The browser downloads HTML, CSS, and JS, assembles the UI the user touches, and talks to backend APIs for data.

The browser requests the page: You type a URL or click a link. The browser asks a server (often a CDN near you) for the page and receives HTML, CSS, and JavaScript files.
It parses HTML into structure: The browser reads the HTML and builds an in-memory tree of every element, the DOM. This is the skeleton the rest hangs on.
It applies CSS and paints: Styles are matched to elements, the layout is calculated, and the browser paints actual pixels: colors, spacing, fonts, position.
JavaScript brings it alive: Scripts run, attach to buttons and inputs, and wait for events. Now clicking, typing, and scrolling actually do something.
The UI talks to the backend: When you submit a form or load more results, JavaScript calls a backend API over the network, gets data back, and updates the screen, no full reload needed.

Frontend vs backend: who owns what

The clearest way to understand the role is by its boundary. Frontend and backend are two halves of the same app that meet at the API, the contract for what data gets sent and received. Everything on the user's side of that contract is the frontend's responsibility; everything behind it belongs to the backend.

Responsibility	Frontend owns	Backend owns
Where the code runs	The user's browser	Servers the team controls
Core languages	HTML, CSS, JavaScript / TypeScript	Python, Go, Java, Node, etc.
Main job	Render the UI, handle interaction	Store data, run business logic
"Login" feature	The form, validation, error states, redirect	Check the password, issue a session token
Performance focus	Load time, smooth interaction, bundle size	Query speed, throughput, uptime
Data	Display it, never the source of truth	The source of truth (databases)
Security focus	Input handling, XSS, safe rendering	Auth, authorization, data protection

The same feature, split across the API boundary.

💡 The grey zone is real: Plenty of work straddles the line, form validation often lives in both places, and a "full-stack" engineer crosses it daily. The table is a map of ownership, not a wall. Knowing the boundary makes you a better teammate even when you step over it.

The modern skill set (beyond "just styling")

If you only learn HTML, CSS, and a little JavaScript, you can build a page. To build a product people rely on, the modern role asks for more. Here is the real surface area of the job today.

The three core languages, deeply, not just "making it look right" in CSS but understanding layout, the box model, and responsive design, and writing JavaScript that handles real logic.
A framework like React, Vue, Svelte, or Angular, the industry builds large UIs as reusable components, not hand-written pages.
Working with APIs, fetching data, handling loading and error states, and showing the right thing while the user waits.
Responsive and cross-browser, one codebase that works on phones, tablets, and laptops, across different browsers.
Accessibility (a11y), building so people using keyboards and screen readers can use the app too. This is a baseline, not a bonus.
Performance, keeping bundles small and interactions smooth, because users abandon slow pages.
Tooling and Git, build tools, package managers, and version control are part of the daily workflow.
Collaboration with design, turning mockups into pixel-faithful, interactive interfaces.

Common misconceptions

"Frontend is just CSS / making things pretty." Styling is one skill among many. The hard parts are state, data flow, performance, and accessibility, all logic.
"It's the easy half of web dev." It is different, not easy. You debug across browsers and devices you do not control, which is its own kind of hard.
"You don't need to understand the backend." You consume its APIs constantly. Knowing how the backend thinks makes you faster and your bug reports sharper.
"A framework is all you need to learn." Frameworks come and go. Solid HTML, CSS, and JavaScript fundamentals outlast every one of them.
"Design and frontend are the same job." Designers decide what it should look like; frontend engineers build it so it works, and the best ones speak both languages.

Takeaways

The whole article in six lines

A frontend engineer builds the user-facing layer, the interface that runs in the browser.
HTML is structure, CSS is presentation, JavaScript is behaviour.
The browser is the runtime: you ship code to a machine you do not control.
Frontend and backend meet at the API; everything on the user's side is yours.
The modern role is engineering, not styling: components, data, performance, accessibility.
Fundamentals outlast frameworks, learn the three core languages deeply.

Where to go next

Now that you know what the role is, the next step is understanding the runtime it lives in and the three languages it is built on. Start with how the browser turns files into pixels, then go deep on each core language.

How the Browser Renders a Page, what really happens between request and pixels.
CSS Fundamentals: The Box Model and Layout, the model behind every layout you will ever build.
JavaScript for the Browser, the language that makes the page do things.
Ready to commit? Follow the structured Frontend Engineer career path from foundation to senior.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.

API Design: Evolution & Versioning

Sri Balaji — Tue, 06 Oct 2026 17:00:14 +0000

⚡ TL;DR: The rule that keeps clients alive: you can add fields, never remove or rename them. Make changes additive, version only for true breaks, run side-by-side with a real deprecation policy, and let contract testing catch breakage before users do.

The day one field rename took down every phone
The one rule: you can add, you cannot take away
The lifecycle: v1 and v2 live side by side
What is safe vs what breaks
Versioning strategies: where the version lives
Code: an additive change done right
Common mistakes that cost hours
Takeaways
Where to go next

The day one field rename took down every phone

It was a one-line change. A field called user_name had always bothered the team, it should have been username, one word, like the rest of the schema. So someone renamed it. The pull request was tiny, the tests were green, the deploy was clean. Twenty minutes later, support lit up: the mobile app was showing blank profiles for every user on every version of the app, all at once.

Nothing was down. The server returned 200. The database was fine. The problem was that three years of shipped mobile binaries were all reading response.user_name, and that key had simply vanished. You cannot push a hotfix to a phone in the App Store review queue. The fix was to redeploy the old field, and then live with user_name forever.

That is the whole discipline of API evolution in one story: the moment someone depends on your shape, the shape is a promise. This article is about keeping that promise while still letting your API grow.

📌 Who this is for: Backend engineers who own an API that real clients already consume, mobile apps, partner integrations, other internal services. If you have ever been afraid to change a response because you do not know who reads it, this is for you. We build on REST API Design and assume you know what a JSON response looks like.

The one rule: you can add, you cannot take away

You can add to an API. You cannot take away from it. Every field you remove and every name you change is a promise broken to someone who already trusted the old shape.

This is sometimes called the robustness principle applied to APIs, and it has a clean asymmetry. Adding a new optional field, a new endpoint, or a new enum value that old clients can ignore is safe, nobody was depending on the absence of a thing. Removing a field, renaming it, making an optional field required, or changing its type is unsafe, somebody, somewhere, is reading exactly what you just changed.

In the real world	In tech
A contract both parties already signed	Your published API response shape
Adding a new clause both sides agree to later	Adding a new optional field
Quietly deleting a clause the other party relies on	Removing or renaming a field
A signed amendment with a start date	A new API version, announced and dated
A notice period before the old terms expire	A deprecation window before sunset

An API is a signed contract, not a private implementation detail.

The mental shift: your API is not your code. Your code is yours to refactor freely. Your API is a contract you co-signed with every client. You do not get to edit a signed contract unilaterally, you either add an amendment everyone accepts, or you issue a new version and give people time to move.

The lifecycle: v1 and v2 live side by side

When a change truly cannot be made additively, you do not flip a switch. You run the old and new shapes in parallel, announce a deprecation, and only then sunset the old one. Here is the shape of that lifecycle.

v1 and v2 served together, then v1 is deprecated, then sunset, clients migrate in the gap.

The key insight is the shared Domain logic node. Both versions call the same core; they differ only at the edge, in how they shape the response. A version is a translation layer, not a fork of your business logic. The Usage metrics node is what tells you when it is actually safe to sunset v1, never sunset on a guess.

Ship v2 alongside v1: Add the new shape behind a new version. v1 keeps working untouched. Both handlers call the same domain core so behaviour stays identical.
Announce the deprecation: Mark v1 deprecated in the docs, return a Deprecation and Sunset header on v1 responses, and tell known clients directly. Give a real date.
Measure who still calls v1: Instrument the v1 handler. You cannot sunset what you cannot see. Watch the call count trend toward zero, and identify the stragglers by API key.
Nudge the stragglers: As the date nears, email the remaining callers, raise the log level, optionally inject brief artificial latency or warning bodies. Do not surprise anyone.
Sunset v1: Once usage is at (or near) zero and the date has passed, return 410 Gone for v1, then delete the handler. The contract has ended on agreed terms.

What is safe vs what breaks

Most of the day-to-day skill is simply knowing which bucket a change falls into. Additive changes ship any time, no version bump. Breaking changes force the lifecycle above. Memorize this table and most of the fear goes away.

Change	Additive / safe	Breaking
Add a new optional field to a response	Yes, old clients ignore it
Add a new endpoint or method	Yes, nobody called it before
Add a new optional request parameter	Yes, old callers omit it, you default it
Add a new value to an enum	Usually, only if clients tolerate unknowns	If clients hard-switch on known values
Remove or rename a response field		Yes, the rename that broke the phones
Make an optional field required		Yes, old requests now fail validation
Change a field's type or format		Yes, `"42"` to `42` breaks parsers
Tighten validation / shrink a range		Yes, previously valid input now rejected
Change default behaviour or sort order		Yes, silent breakage, the worst kind

The two buckets every API change falls into.

⚠️ Warning: Enum additions are the classic trap. Adding a new status value is additive only if every client treats unknown values gracefully. Plenty of clients do switch (status) with no default and crash on anything new. Document, from day one, that clients must tolerate unknown enum members, then additions stay safe.

Versioning strategies: where the version lives

When you do need a breaking version, the question is where the version number goes. There are three mainstream answers, and the honest truth is that the best one is usually none of them, keep changes additive and never bump at all.

Strategy	How it looks	Trade-off
Additive-only (no version)	`/users/42` forever; only ever add fields	Best default, no migration, no sprawl. Requires discipline: you can never take away
URI versioning	`/v1/users/42` then `/v2/users/42`	Dead obvious, cache-friendly, easy to route. But the URL of a resource changes, which is conceptually wrong, and tends to breed v3, v4, v5
Header versioning	`Accept: application/vnd.api.v2+json`	URL stays stable per resource; clean in theory. But invisible in a browser, harder to cache and debug, easy to forget to set

Three strategies for breaking versions, plus the one you should reach for first.

Pick additive-only as your default. Reach for URI versioning when you genuinely need a clean break and you value how visible and routable it is, it is the most common choice for public APIs precisely because it is impossible to misread. Reach for header versioning only if a stable resource URL matters more to you than ease of debugging, and your clients are disciplined services rather than humans poking at URLs.

Whatever you pick, version the whole API, not individual fields. Per-field versioning (name_v2, name_v3) is how you end up with a response object that is a museum of every decision you ever regretted. One version axis, applied consistently.

Code: an additive change done right

Here is the rename from the opening story, done the safe way. We never remove user_name. We add username next to it, both populated from the same source. Old clients keep reading the old key; new clients adopt the new one. No version bump needed, this is pure addition.

GET /users/42, response evolves additively

// BEFORE: the original contract
{
  "id": 42,
  "user_name": "sribalaji",
  "email": "sri@example.com"
}

// AFTER: additive, old key stays, new key added.
// Both are populated. Nothing is removed, so nothing breaks.
{
  "id": 42,
  "user_name": "sribalaji",   // deprecated, still served for old clients
  "username": "sribalaji",     // preferred, new clients read this
  "email": "sri@example.com",
  "display_name": "Sri Balaji" // brand-new optional field, also safe
}

On the server, the contract is something you assert against, not something you let drift. A contract test pins the shape so a careless refactor fails CI instead of failing production. Here is the idea in TypeScript.

user.contract.test.ts

import { describe, it, expect } from "vitest";
import { getUser } from "./api";

describe("GET /users/:id contract", () => {
  it("keeps every field old clients depend on", async () => {
    const res = await getUser(42);

    // These keys are PROMISES. Removing one must fail here,
    // loudly, in CI, long before it reaches a phone.
    expect(res).toHaveProperty("id");
    expect(res).toHaveProperty("user_name"); // deprecated, still required
    expect(res).toHaveProperty("email");

    // Types are part of the contract too.
    expect(typeof res.id).toBe("number");
    expect(typeof res.user_name).toBe("string");
  });

  it("may add new fields freely", async () => {
    const res = await getUser(42);
    // Additive fields are allowed, we assert presence, not absence.
    expect(res).toHaveProperty("username");
  });
});

Contract tests are the seatbelt for the whole discipline. In a multi-service shop, consumer-driven contracts go further: each consumer publishes the subset of the shape it actually reads, and the provider's CI verifies it never breaks any published expectation. The provider learns it broke a client before deploying, not after.

Common mistakes that cost hours

Renaming or removing a field in place. The original sin from the opening story. If the name is wrong, add the right one beside it and deprecate the old one. Never delete a field someone might read.
No deprecation window. Marking something deprecated and removing it the same week is not a deprecation, it is an ambush. Announce a date, return Deprecation and Sunset headers, and measure usage until it is genuinely zero.
Sunsetting on a guess. Removing v1 because "surely nobody uses it anymore" without metrics. Instrument the old path first. The one straggler is always your biggest partner.
Version sprawl. Bumping the major version for a change that could have been additive. Every live version is a maintenance tax forever. Most changes should add a field, not a /v3.
Per-field or per-endpoint versions. name_v2, /v3/users next to /v1/orders, now nobody knows what "the API version" even means. One version axis, applied to the whole surface.
Tightening silently. Shrinking a max length, adding a required field, or changing a default sort. These pass your tests and break clients quietly. Treat any narrowing of accepted input as breaking.

Takeaways

The whole article in seven lines

You can add to an API; you cannot take away. The moment a client reads your shape, the shape is a promise.
Additive changes, new optional fields, new endpoints, new tolerated enum values, ship any time, no version bump.
Breaking changes, renames, removals, type changes, new required fields, tighter validation, force the full lifecycle.
The lifecycle is: serve v2 beside v1 → announce deprecation with a date → measure real usage → nudge stragglers → sunset.
Default to additive-only (no version). Reach for URI versioning for visibility, header versioning only for stable URLs.
Version the whole API on one axis. Per-field versions and v3/v4/v5 sprawl are how you drown in maintenance.
Contract tests (and consumer-driven contracts) catch a broken promise in CI instead of in the App Store review queue.

Where to go next

Evolution is one pillar of API design. Pair it with the fundamentals of resource modelling and the security model so the contract you are so carefully preserving is also a good contract to begin with.

Start with REST API Design, get the resource shapes right before you have to evolve them.
Then read Secure API Design, versioning a leaky contract just preserves the leak.
Follow the full Backend Engineer path to see where API evolution sits among data modelling, messaging, and reliability.
Practice routing and gateways in the networking lab, the gateway is where version routing actually lives.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.

Database Transactions & Consistency

Sri Balaji — Mon, 05 Oct 2026 19:32:44 +0000

⚡ TL;DR: Transactions guarantee all-or-nothing, but the lever that actually prevents anomalies is your isolation level. Learn to pick it deliberately, choose optimistic vs pessimistic locking by contention, and stop treating eventual consistency as a bug.

Two transfers, one disappearing $100
What a transaction promises
The shape of a transaction
Isolation levels and the anomalies they prevent
Doing it in SQL: commit, rollback, and locking
Optimistic vs pessimistic, and a word on eventual consistency
Common mistakes that cost hours
Takeaways
Where to go next

Two transfers, one disappearing $100

Alice has $100. At 12:00:00.000 two transfer requests hit your server at the same time: one moves $100 to Bob, the other moves $100 to Carol. Each request runs the same code: read Alice's balance ($100), check it's enough (it is), subtract $100, write the new balance ($0). Both reads happen before either write lands. Both checks pass. Both writes succeed. Bob gets $100, Carol gets $100, and Alice's balance is $0, not -$100. You just created $100 out of thin air.

Nobody wrote a bug. The logic is correct for one request at a time. It falls apart because two requests interleaved, and nothing forced them to take turns. This is the entire reason database transactions exist: to make a sequence of steps behave as if it were a single, indivisible, isolated operation, even when thousands of them run concurrently.

📌 Who this is for: Backend engineers who use BEGIN/COMMIT but have never been bitten hard enough to learn why they matter. You'll leave understanding ACID concretely, knowing which isolation level prevents which anomaly, when to reach for optimistic vs pessimistic locking, and what "eventual consistency" actually buys and costs. No CS degree assumed.

What a transaction promises

A transaction is a group of operations that the database treats as a single unit: all of them happen, or none of them do, and to everyone else it looks instantaneous.

The one-sentence definition of ACID

The classic example is a bank transfer. Moving $100 from Alice to Bob is really two writes: subtract $100 from Alice, add $100 to Bob. If the server crashes between them, you must never end up in a world where Alice was debited but Bob was never credited. The money has to fully move or not move at all. A transaction is the contract that guarantees exactly that.

In the real world	In tech
The transfer either fully completes or is fully torn up, never half-done.	Atomicity, all writes commit, or all roll back.
Money is never created or destroyed; the books always balance afterward.	Consistency, every committed state satisfies your constraints and invariants.
While you're mid-transfer, nobody else sees Alice debited but Bob not yet credited.	Isolation, concurrent transactions don't see each other's partial work.
Once the receipt prints, the money stays moved even if the power dies a second later.	Durability, a committed transaction survives crashes and restarts.

ACID, mapped to a single bank transfer.

Those four letters are ACID. Atomicity and durability are mostly the database's job, it writes to a durable log before it acknowledges your COMMIT. Consistency is shared: the database enforces the constraints you declare (foreign keys, CHECK, UNIQUE), but it can't know your business rules unless you encode them. Isolation is the subtle one, and where most real bugs live, it's where the $100-from-thin-air problem hides.

The shape of a transaction

Every transaction has the same skeleton: you BEGIN, run one or more operations, then either COMMIT (make it permanent and visible) or ROLLBACK (throw it all away as if it never happened). Below, two transactions run against the same rows at once, and isolation is what decides what each one is allowed to see of the other.

One transaction's lifecycle (top row) and a second concurrent transaction (bottom row) contending for the same rows; isolation governs what each sees of the other's uncommitted work.

BEGIN: You open a transaction. The database takes a consistent snapshot point and starts tracking every change you make so it can undo them if needed.
Run operations: Your reads and writes happen, but to other sessions they're invisible (or visible-but-blocked, depending on isolation level). Nothing is permanent yet.
Decide: COMMIT or ROLLBACK: If every step succeeded, COMMIT durably writes the changes and makes them visible to everyone. If anything failed, ROLLBACK discards every change, the database returns to exactly its pre-BEGIN state.
Concurrency is resolved here: When Txn A and Txn B touch the same rows, the isolation level decides whether B sees A's uncommitted data, blocks until A finishes, or fails with a conflict it must retry.

Isolation levels and the anomalies they prevent

Perfect isolation is expensive, making every transaction take strict turns kills throughput. So SQL defines a ladder of isolation levels that trade safety for concurrency. Each rung permits certain anomalies: weird results caused by interleaving. Know the three you'll meet most:

Dirty read, you read a row another transaction has changed but not yet committed. If it rolls back, you acted on data that never officially existed.
Non-repeatable read, you read a row twice in one transaction and get different values, because someone else committed an UPDATE in between.
Phantom read, you run the same WHERE query twice and get a different set of rows, because someone else committed an INSERT or DELETE matching your filter.

Isolation level	Dirty read	Non-repeatable read	Phantom read
Read uncommitted	Allowed	Allowed	Allowed
Read committed	Prevented	Allowed	Allowed
Repeatable read	Prevented	Prevented	Allowed*
Serializable	Prevented	Prevented	Prevented

The four standard SQL isolation levels and which anomalies each still allows. Lower in the table = safer but more contention.

💡 Defaults differ, check yours: PostgreSQL defaults to Read committed; its Repeatable read is snapshot-based and actually prevents phantoms too (the * above), and its Serializable detects conflicts and aborts one transaction to retry. MySQL/InnoDB defaults to Repeatable read. Never assume, SHOW transaction_isolation; and read your engine's docs, because the same level name can mean subtly different things.

The practical rule: Read committed is a sane default for most CRUD apps. Bump to Repeatable read or Serializable only for transactions where correctness depends on a stable view, like a report that sums rows it also reads back, or a balance check that must hold for the whole transaction. Higher levels mean more blocking and more retryable conflicts, so pay for them only where you need them.

Doing it in SQL: commit, rollback, and locking

Here's the bank transfer done correctly, wrapped in a transaction so it's all-or-nothing, with an explicit ROLLBACK path. The CHECK keeps the books consistent even if logic slips.

transfer.sql

BEGIN;

-- Debit Alice; the CHECK constraint refuses to let her go negative
UPDATE accounts
   SET balance = balance - 100
 WHERE id = 'alice' AND balance >= 100;

-- If no row matched (insufficient funds), bail out and undo everything
-- (application checks the affected row count; on 0 it issues:)
--   ROLLBACK;

-- Credit Bob
UPDATE accounts
   SET balance = balance + 100
 WHERE id = 'bob';

COMMIT;  -- both writes land together, or neither does

But two concurrent transfers can still race, the lost-update problem from the hook. There are two ways to stop it. Pessimistic locking grabs the row up front so nobody else can touch it until you're done:

pessimistic.sql

BEGIN;

-- Lock Alice's row: any other txn that also does SELECT ... FOR UPDATE
-- (or tries to UPDATE it) blocks here until this transaction ends.
SELECT balance FROM accounts WHERE id = 'alice' FOR UPDATE;

-- Now we hold the lock; the read-check-write is safe.
UPDATE accounts SET balance = balance - 100 WHERE id = 'alice';
UPDATE accounts SET balance = balance + 100 WHERE id = 'bob';

COMMIT;  -- lock releases here

Optimistic locking assumes conflicts are rare. You don't lock, you add a version column, read it, and only write if it hasn't changed since you read it. If someone else got there first, your UPDATE affects zero rows and you retry:

optimistic.sql

-- Step 1: read the row AND its current version (no lock held)
SELECT balance, version FROM accounts WHERE id = 'alice';
--   -> balance = 100, version = 7

-- Step 2: write only if the version is still 7. Note version bumps.
UPDATE accounts
   SET balance = balance - 100,
       version = version + 1
 WHERE id = 'alice' AND version = 7;

-- Step 3: check the affected row count.
--   1 row  -> success, you won the race.
--   0 rows -> someone else updated first (version is now 8);
--             re-read and retry the whole operation.

Optimistic vs pessimistic, and a word on eventual consistency

Neither lock is "better", they're bets on how often conflicts happen. Pessimistic locking prevents conflicts by blocking; it's right when contention is high or the work between read and write is short, but it costs throughput and risks deadlocks if you lock rows in inconsistent orders. Optimistic locking lets everyone proceed and only pays a cost when a conflict actually occurs; it shines under low contention and for long think-time (e.g. a user editing a form for two minutes), but you must handle the retry path or you'll silently drop the loser's write.

	Pessimistic	Optimistic
Mechanism	Lock the row (FOR UPDATE)	Version/timestamp check on write
Best when	High contention, short critical section	Low contention, long think-time
Cost	Blocking, deadlock risk	Retries when conflicts occur
Failure mode	Waits / timeouts	Write affects 0 rows, must retry

Choosing a concurrency strategy.

Everything so far assumes one database that can give you a single, instantly-consistent answer. Spread data across many machines and you hit the CAP trade-off: when the network between nodes breaks (a Partition), you can only keep one of Consistency (every read sees the latest write) or Availability (every request still gets an answer). You can't have both during a partition, and partitions are not optional, so the real choice is C-vs-A under failure.

Many distributed stores pick availability and offer eventual consistency: a write may not be visible everywhere immediately, but if writes stop, all replicas converge to the same value given enough time. That's why you sometimes post a comment and don't see it on a refresh, your read hit a replica that hadn't caught up. It's a perfectly good trade for likes, feeds, and caches; it's a terrible trade for account balances, which is exactly where you keep a strongly-consistent, ACID-transactional database. Pick per-use-case, not per-religion. (More on the storage side in SQL vs NoSQL.)

Common mistakes that cost hours

No transaction around multi-step writes. Any operation that's two or more writes (transfer, order + line items, create-user + create-profile) must be one transaction. Without it, a crash or error leaves you half-written and corrupt.
Wrong isolation level. Running a balance check or a sum-and-reconcile at Read committed lets values shift mid-transaction. Match the level to the invariant you need to hold; default Read committed is not enough for everything.
Long-running transactions. Holding a transaction open across a network call, an external API, or user think-time keeps locks and snapshots alive, bloating the database and blocking others. Keep transactions short; do slow work outside them.
Ignoring the lost update. Read-modify-write without FOR UPDATE or a version check is the $100-from-thin-air bug. Pick pessimistic or optimistic locking, "neither" is a silent data-loss bug waiting to happen.
Catching errors but not rolling back. If you swallow an exception mid-transaction and keep going, you may COMMIT partial work. Always ROLLBACK on any failure inside the transaction.

Takeaways

The whole article in seven lines

A transaction makes many operations behave as one: all commit, or all roll back.
ACID = Atomicity, Consistency, Isolation, Durability, isolation is where real bugs hide.
Anomalies climb a ladder: dirty read → non-repeatable read → phantom read.
Isolation levels trade safety for concurrency; Read committed is a sane default, raise it only where an invariant demands a stable view.
Stop lost updates with pessimistic locking (FOR UPDATE) or optimistic locking (a version column + retry).
Across machines, CAP forces a Consistency-vs-Availability choice during partitions.
Eventual consistency converges over time, great for feeds, wrong for balances.

Where to go next

You now have the vocabulary to reason about correctness under concurrency, the foundation under every backend that touches money, inventory, or counts. Build on it:

Decide where your transactional data lives, read SQL vs NoSQL to weigh strong consistency against scale.
Move slow work out of transactions and off the request path with Async Processing: Queues & Workers.
See how these fit a full role on the Backend Engineer path.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.

Async Processing: Queues & Workers

Sri Balaji — Sun, 04 Oct 2026 15:35:33 +0000

⚡ TL;DR: Move slow work off the request path with queues and workers so APIs stay fast. The catch: at-least-once delivery means you must make workers idempotent and add retries plus a dead-letter queue, or duplicates and lost jobs will bite.

The checkout that times out
The principle: acknowledge fast, do the slow work later
The picture: API to queue to worker pool
Sync vs async: what you are actually trading
Enqueue a job, write an idempotent worker
Idempotency, retries, and the dead-letter queue
Common mistakes that cost hours
Takeaways
Where to go next

The checkout that times out

A customer clicks Place order. Your handler charges the card, writes the order row, then, still inside the same HTTP request, renders a receipt, calls the email provider, pings the warehouse webhook, and updates the analytics warehouse. The card charge took 200ms. Everything after it took 4 seconds. The mobile client gave up at 3, showed a spinning error, and the customer tapped Place order again.

Now you have two charges, one angry customer, and a support ticket. Nothing was broken, the code did exactly what you wrote. The mistake was where you ran the slow work: inline, in the request path, holding the user hostage while you talked to three external systems that have nothing to do with whether the order succeeded.

The order was done the moment the charge cleared and the row was written. The email, the webhook, the analytics, those are follow-up work. They should not be able to slow down, or fail, the thing the user is actually waiting for. This is the problem async processing solves.

📌 Who this is for: Backend engineers who can build a CRUD API and now need to make it fast and resilient under real load. You should be comfortable with HTTP request/response and a database. You do not need prior queue experience, we build the mental model from zero. If you have shipped a feature that "sometimes sends two emails," this article is for you.

The principle: acknowledge fast, do the slow work later

Do the minimum work needed to keep your promise to the user, acknowledge immediately, and push everything else onto a queue for a worker to finish in the background.

The async processing rule

The request path should only contain work that is required for correctness and that the user is waiting on the result of. Charging the card qualifies. Sending a confirmation email does not, the user does not stare at the screen until the email lands. So the handler does the essential bit, drops a message describing the rest onto a queue, and returns 202 Accepted in milliseconds. A separate process picks the message up later and does the slow part.

This splits one fragile synchronous chain into two independent halves. The producer (your API) only needs the queue to be up. The consumer (your worker) can be slow, can restart, can fail and retry, and the user never sees any of it. You have traded a tiny bit of immediacy (the email arrives in 2 seconds, not 0) for a large amount of latency and reliability.

In the real world	In tech
Waiter clips the order ticket to the rail and walks away	Producer enqueues a job and returns immediately
The ticket rail holding orders in line	The message queue buffering jobs
Cooks pull the next ticket when they are free	Worker pool pulling jobs at its own pace
A rush doesn't stop waiters taking orders, tickets just pile up	Load spike doesn't slow the API; the queue absorbs the backlog
A dropped dish gets re-fired from the same ticket	A failed job is retried from the same message

A busy restaurant kitchen is a producer/consumer system you have already seen work.

The picture: API to queue to worker pool

The API enqueues a job and returns instantly. A pool of workers pulls jobs from the queue and processes them. Jobs that keep failing branch off to a dead-letter queue for humans to inspect.

Client calls the API: POST /orders. The user is now waiting on this single request, so it must be fast.
API does the essential work: Charge the card, write the order row in the database. This is the part the user actually cares about.
API enqueues a job: It writes a small message, { type: "send_receipt", orderId: 8842 }, onto the queue. This is a sub-millisecond local call.
API returns 202 immediately: The user sees a confirmation in under 300ms. The slow follow-up work hasn't happened yet, and that's fine.
A worker pulls the job: Whenever a worker in the pool is free, it grabs the next message and processes it, sends the email, calls the webhook.
Worker acknowledges success: On success it tells the queue to delete the message. On repeated failure, the message is routed to the dead-letter queue for a human.

Sync vs async: what you are actually trading

Async is not free, and it is not always right. A read that returns data the user needs now must stay synchronous. The trade is concrete: you spend complexity to buy latency and reliability. Know what you are buying.

Dimension	Synchronous (inline)	Asynchronous (queue + worker)
User-perceived latency	Sum of every step, as slow as the slowest dependency	Only the essential work; follow-up runs later
Reliability	One downstream failure fails the whole request	Downstream failure is isolated, retried, and invisible to the user
Load spikes	Each request holds resources until done; pile-ups cascade	Queue absorbs the burst; workers drain it at a steady rate
Complexity	Low, one process, easy to reason about	Higher, a broker, workers, retries, idempotency, monitoring
Failure visibility	Immediate, user sees the error	Deferred, you need dashboards and a DLQ to see failures
Best for	Reads the user is waiting on; work required for the response	Emails, webhooks, thumbnails, exports, anything fire-and-forget

Doing slow work inline vs. handing it to a queue and worker.

Enqueue a job, write an idempotent worker

Here is the producer side. The API charges the card, writes the order, then enqueues a tiny message. Notice the message carries an idempotency key, we will use it to make the worker safe to run more than once.

api/orders.py

import uuid

def place_order(request):
    # 1. Essential work the user is waiting on.
    charge = payments.charge(request.card, request.amount)
    order = db.orders.insert(
        user_id=request.user_id,
        amount=request.amount,
        charge_id=charge.id,
    )

    # 2. Enqueue the slow follow-up work. Sub-millisecond local call.
    queue.send({
        "type": "send_receipt",
        "order_id": order.id,
        # A stable key so retries don't duplicate side effects.
        "idempotency_key": f"receipt:{order.id}",
    })

    # 3. Return immediately. The email hasn't been sent yet, that's fine.
    return Response(status=202, body={"order_id": order.id})

And the consumer. The queue guarantees the message is delivered at least once, which means it may be delivered twice. The worker must produce the same result whether it runs once or five times. We enforce that by recording the idempotency key before doing the side effect, inside a unique constraint.

worker/handlers.py

def handle_send_receipt(msg):
    key = msg["idempotency_key"]

    # Claim the work atomically. If this key was already processed,
    # the unique index raises and we skip the side effect entirely.
    try:
        db.processed_jobs.insert(key=key)  # UNIQUE(key)
    except UniqueViolation:
        return ack(msg)  # already done, safe to drop the duplicate

    # Only now do the non-repeatable side effect.
    order = db.orders.get(msg["order_id"])
    email.send_receipt(order.user_email, order)

    return ack(msg)  # tell the queue to delete the message

💡 Ack means "done", not "received": A worker should acknowledge a message only after the work has fully succeeded. If the worker crashes before acking, the queue redelivers the message to another worker, that is exactly how at-least-once delivery recovers from crashes. Ack too early and a crash silently loses the job.

Idempotency, retries, and the dead-letter queue

At-least-once delivery is why idempotency is mandatory

Almost every production queue (SQS, RabbitMQ, Kafka) delivers at least once, not exactly once. "Exactly once" across a network and a crash is famously close to impossible. So you must assume any message can arrive more than once: a worker processed it, sent the email, then crashed before acking, the queue redelivers, and a second worker sends the email again. Idempotency is the property that processing the same message twice has the same effect as processing it once. The unique-key check above is how we get it: the first run claims the key, every duplicate hits the constraint and short-circuits.

Retries with backoff

When a job fails, the email provider is down, the network blipped, you do not drop it, you retry. But retry with exponential backoff and jitter: wait 1s, then 2s, then 4s, then 8s, with a little randomness so a thousand failed jobs don't all retry in lockstep and hammer the recovering dependency. Crucially, retries must be bounded. An infinite retry loop on a permanently-bad message (a "poison message") will spin forever, burn CPU, and block the queue.

The dead-letter queue catches what can't succeed

After N failed attempts (5 is a common default), the broker moves the message to a dead-letter queue, a separate queue for messages that could not be processed. The DLQ is your safety net: nothing is silently lost, the bad message stops blocking the main queue, and a human (or an alert) can inspect it, fix the root cause, and replay it. A queue without a DLQ either loses messages or jams forever. Always wire one up, and always alert on DLQ depth greater than zero.

Common mistakes that cost hours

Non-idempotent handlers. Assuming each message arrives exactly once. Under at-least-once delivery, a duplicate means a double charge or a double email. Make every handler safe to re-run before you ship it.
No dead-letter queue. Without a DLQ, a poison message either gets lost on the last failed attempt or retries forever and blocks everything behind it. Configure a DLQ and alert when it is non-empty.
Infinite retries. Retrying a permanently-bad message forever wastes resources and starves healthy jobs. Bound retries, use exponential backoff with jitter, then dead-letter.
Assuming message ordering. Most queues do not guarantee order across messages, and a worker pool processes them in parallel anyway. If "updated" can be processed before "created", your data corrupts. Don't depend on order, or use an ordered/FIFO queue with a partition key and accept the throughput cost.
Acking before the work is done. Acknowledging on receipt instead of on success turns every worker crash into a silently dropped job.
Fat messages. Putting a 5MB payload on the queue instead of an ID the worker re-fetches. Keep messages small; pass references, not data.

Takeaways

The whole article in seven lines

Keep the request path to work the user is waiting on; acknowledge fast and push the rest onto a queue.
Producer enqueues and returns 202; a worker pool consumes and does the slow side effects later.
Queues deliver at-least-once, so every message can arrive twice. Idempotency is mandatory, not optional.
Make handlers idempotent by claiming a stable idempotency key under a unique constraint before the side effect.
Ack only after success; a crash before ack triggers redelivery, which is how the system self-heals.
Retry with bounded exponential backoff and jitter; route exhausted messages to a dead-letter queue and alert on it.
Never assume ordering across messages unless you explicitly use a FIFO queue with a partition key.

Where to go next

Async processing is one pillar of building backends that stay fast and reliable under load. Pair it with the broader scaling patterns and the data-consistency rules that decide what the producer must do before it enqueues.

Scalability Principles, where queues fit among caching, load balancing, and horizontal scaling.
Database Transactions & Consistency, why the charge and the order row must commit together before you enqueue follow-up work.
Follow the full Backend Engineer path to see how async processing connects to the rest of the curriculum.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.

Authentication & Sessions in Backends

Sri Balaji — Sat, 03 Oct 2026 15:00:53 +0000

⚡ TL;DR: Verifying a password is step one. The real decision is server sessions vs JWTs, and the part most people botch is logout and revocation. Get cookies, hashing, and token revocation right or pay in hours debugged or a breach.

You can verify a password. Now what?
The mental model: a coat-check ticket
The picture: one login, then many requests
Server sessions vs stateless JWTs
The code: hash, verify, then issue a ticket
Cookies done right (and refresh tokens)
Logout and revocation, the part people skip
Common mistakes that cost hours (or a breach)
Takeaways
Where to go next

You can verify a password. Now what?

Your login endpoint works. A user POSTs an email and password, you check them, and the response says "welcome back." Then the very next request comes in, GET /orders, and the server has no idea who is asking. HTTP is stateless: every request arrives as a stranger. The whole job of authentication in a backend is to turn one successful login into a stream of requests the server can keep trusting, without asking for the password again.

That sounds simple, and that is exactly why it goes wrong. People store passwords in plaintext. They put a secret token in localStorage where any script can read it. They issue tokens that never expire and can never be revoked, so a leaked credential is valid forever. This article is the backend implementation companion to Authentication vs Authorization, that piece explains the concepts; this one shows you how to actually build the login-and-session machinery without leaving a hole in it.

📌 Who this is for: Backend developers who can write a route handler but have never built auth from scratch, or have copy-pasted it and aren't sure which parts are load-bearing. You'll leave knowing how to hash a password, choose between sessions and JWTs, set cookies safely, and log a user out for real. No prior security background needed.

The mental model: a coat-check ticket

Authentication answers "who are you?" exactly once. Everything after that is the server recognizing a credential it already issued, so the design problem is really about that credential's lifetime, storage, and revocation.

Think of a coat check. You hand over your coat (your password) once, at the door. In return you get a little numbered ticket. For the rest of the night you never describe your coat again, you just flash the ticket and the attendant hands your coat back. The ticket is worthless to a thief who doesn't know which coat it maps to, it's small enough to carry around, and at the end of the night it stops working.

In the real world	In tech
Handing over your coat at the door	POSTing your password to /login, once
The numbered ticket you get back	A session id or signed JWT
Flashing the ticket all night	Every later request carries the session cookie
The attendant's coat rack	Server-side session store (or the token's own signature)
Ticket stops working at closing time	Expiry, and the ability to revoke it early

Logging in is a one-time exchange. The session id (or token) is the ticket you carry afterward.

The picture: one login, then many requests

Here is the flow end to end. The password is verified once; from then on, each request carries the ticket and the server only has to validate the ticket, a much cheaper, much safer operation.

Login verifies the password hash once; later requests carry and validate a session id or token.

Client submits credentials: The browser POSTs email + password to /login over HTTPS. This is the only request where the raw password travels.
Server verifies the password hash: Look up the user, then compare the submitted password against the stored hash with bcrypt or argon2. You never decrypt, hashes are one-way. The library tells you match or no-match.
Server issues a ticket: On success, mint a credential: either a random session id stored server-side, or a signed JWT the client holds. Attach it to the response as a cookie.
Client carries the ticket: The browser stores the cookie and automatically attaches it to every subsequent request to your domain, no app code required.
Server validates each request: For a session id, look it up in the store and confirm it's live. For a JWT, verify the signature and expiry. If it checks out, you know who's asking.

Server sessions vs stateless JWTs

There are two ways to make a ticket the server trusts. With server sessions, the ticket is just a random id; the real data lives in a store on your side (Redis, a database table). With stateless JWTs, the ticket is the data, a signed blob the client holds, which the server trusts because the signature can't be forged without your secret key. The trade-off is the whole game, and it comes down to one question: how do you revoke?

Dimension	Server sessions	Stateless JWT
Where state lives	Server store (Redis/DB); cookie holds only an opaque id	Inside the token itself; server stores nothing
Revocation	Instant, delete the row and the next request fails	Hard, valid until it expires unless you add a denylist
Scaling	Every node needs to reach the shared store	Any node can verify with just the signing key
Per-request cost	A store lookup on each request	A signature check (CPU only, no I/O)
Size on the wire	Tiny id (~32 bytes)	Bigger, header + claims + signature, sent every request
Best fit	Most web apps; anything needing instant logout	Short-lived API/service tokens, paired with a refresh token

Server sessions vs JWTs, the practical trade-offs.

💡 Default to sessions: If you're unsure, use server sessions. "Stateless" sounds like less work, but the moment you need to log someone out, ban an account, or invalidate everything after a password change, statelessness becomes the problem you have to engineer around. Reach for JWTs when you genuinely can't share a session store, for example, tokens passed between independently deployed services.

The code: hash, verify, then issue a ticket

Below is the core of a login flow in Python. Step one is registration, we hash the password before it ever touches the database. Step two is login, we verify against that hash, then mint a session. Notice we never store, log, or compare the raw password directly.

auth.py

import bcrypt, secrets, time

# --- Registration: hash before storing. NEVER store the raw password. ---
def hash_password(plain: str) -> bytes:
    # bcrypt auto-generates a random salt and embeds it in the output.
    # The cost factor (12) makes each guess deliberately slow for attackers.
    return bcrypt.hashpw(plain.encode(), bcrypt.gensalt(rounds=12))

# users table stores: id, email, password_hash (the bytes above)

# --- Login: verify against the stored hash. ---
def verify_password(plain: str, stored_hash: bytes) -> bool:
    # Constant-time compare; safe against timing attacks. Returns True/False.
    return bcrypt.checkpw(plain.encode(), stored_hash)

# --- Issue a server-side session (the coat-check ticket). ---
sessions = {}  # in real life: Redis, with a TTL

def create_session(user_id: int) -> str:
    sid = secrets.token_urlsafe(32)        # 256 bits of randomness, unguessable
    sessions[sid] = {"user_id": user_id, "expires": time.time() + 7 * 86400}
    return sid

def validate_session(sid: str):
    s = sessions.get(sid)
    if not s or s["expires"] < time.time():
        return None                        # expired or revoked -> reject
    return s["user_id"]

def revoke_session(sid: str):
    sessions.pop(sid, None)                 # logout = delete it. Done.

If you'd rather go stateless, the issue/validate pair becomes a JWT. The shape is the same, mint on login, check on each request, but there's no store, so revocation is no longer free:

jwt_auth.py

import jwt, time   # PyJWT

SECRET = "load-this-from-an-env-var-not-source-code"

def issue_jwt(user_id: int) -> str:
    payload = {
        "sub": str(user_id),
        "iat": int(time.time()),
        "exp": int(time.time()) + 15 * 60,   # short life: 15 minutes
    }
    return jwt.encode(payload, SECRET, algorithm="HS256")

def validate_jwt(token: str):
    try:
        # Verifies the signature AND the exp claim in one call.
        payload = jwt.decode(token, SECRET, algorithms=["HS256"])
        return payload["sub"]
    except jwt.InvalidTokenError:
        return None   # bad signature or expired -> reject

⚠️ Pin the algorithm: Always pass an explicit algorithms=[...] allow-list when decoding a JWT. Libraries that accept the algorithm from the token's own header have shipped catastrophic bugs, an attacker sets alg: none and the signature check is skipped entirely.

Cookies done right (and refresh tokens)

Whichever ticket you chose, deliver it in a cookie, and three flags decide whether that cookie is safe. Getting these wrong is how a working login becomes a vulnerability.

HttpOnly, JavaScript cannot read the cookie. This is the single most important flag: it means a cross-site scripting (XSS) bug can't steal the session. (It's also exactly why you should not keep tokens in localStorage, that's readable by any script.)
Secure, the cookie is only sent over HTTPS, so it never travels in plaintext where it could be sniffed.
SameSite, controls whether the cookie rides along on cross-site requests. Lax is a sane default and blocks most CSRF; Strict is tighter; only use None (with Secure) when you genuinely need cross-site cookies.
Max-Age / Expires, give every cookie a finite lifetime. A ticket that never expires is a permanent key.

set_cookie.py

# Flask example, the same flags exist in every framework.
resp.set_cookie(
    "session",
    sid,
    httponly=True,     # JS can't touch it -> XSS can't steal it
    secure=True,       # HTTPS only
    samesite="Lax",    # CSRF protection
    max_age=7 * 86400, # finite lifetime
)

Refresh tokens solve a tension with JWTs: you want access tokens to be short-lived (so a leak is brief), but you don't want to ask users to log in every 15 minutes. The pattern: issue a short-lived access token plus a long-lived refresh token. When the access token expires, the client trades the refresh token for a new one. Critically, the refresh token is stored server-side (or in a denylist), so it can be revoked, which buys back the logout ability that pure JWTs lack. Keep the refresh token in an HttpOnly cookie too, and rotate it on each use so a stolen one is detectable.

Logout and revocation, the part people skip

Logout is not "delete the cookie in the browser." A stolen cookie still works if the server still honors it. Real logout means invalidating the ticket server-side. With sessions this is one line, delete the row. With pure JWTs you can't, which is the whole catch: the token stays valid until it expires no matter what you do. That's why production JWT setups keep them short-lived and add a denylist of revoked token ids checked on each request, at which point you've re-added the server lookup you adopted JWTs to avoid. It's a real trade-off, not a free lunch.

logout.py

# Session logout: invalidate the ticket, then clear the cookie.
def logout(sid, resp):
    revoke_session(sid)          # server-side: the ticket is now dead
    resp.delete_cookie("session")
    return resp

# "Log out everywhere" = delete every session for the user_id.
# Trivial with sessions; needs a denylist with JWTs.

Common mistakes that cost hours (or a breach)

Storing passwords in plaintext, or hashing with MD5/SHA-1. Those hashes are fast, which is exactly wrong: attackers brute-force them billions per second. Use bcrypt or argon2, which are deliberately slow and salted.
Putting tokens in localStorage. It's readable by any JavaScript on the page, so one XSS bug exfiltrates every user's session. Use HttpOnly cookies instead.
No expiry. A session or token that lives forever turns a single leak into permanent access. Always set a finite lifetime.
No revocation path. If you can't kill a session on logout, password change, or account ban, you can't respond to a compromise. Design revocation in from day one, it's the main reason to prefer sessions.
Accepting the JWT's own alg header. Always pin the verification algorithm; never let the token tell you how to verify itself.
Returning different errors for "no such user" vs "wrong password." That leaks which emails are registered. Return one generic "invalid credentials" for both.

Takeaways

The whole article in seven lines

HTTP is stateless, auth turns one login into a stream of trusted requests via a ticket.
Never store raw passwords; hash with bcrypt or argon2 (slow + salted), never MD5/SHA-1.
Server sessions = state on your side, instant revocation. JWTs = stateless, but revocation is hard.
Default to sessions; reach for JWTs only when you can't share a session store.
Deliver the ticket in an HttpOnly + Secure + SameSite cookie with a finite lifetime, never localStorage.
Refresh tokens let access tokens stay short-lived without forcing constant re-login.
Logout means invalidating the ticket server-side, not just clearing the browser cookie.

Where to go next

Authentication answers "who are you?", the next question is "what are you allowed to do?" Read the concept companion to this piece, then see how auth fits into a hardened API surface, and continue along the Backend Engineer track.

Authentication vs Authorization, the concepts behind everything you just built.
Secure API Design, where sessions, tokens, and cookies fit into a safe API surface.
Backend Engineer path, the full track this article belongs to.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.

Caching Strategies: Make Backends Fast Without Melting the Database

Sri Balaji — Fri, 02 Oct 2026 16:26:25 +0000

⚡ TL;DR: Stop making the database redo the same work a thousand times a second. Compare cache-aside, read-through, write-through, and write-behind, set sane TTLs, and survive the two hard problems: invalidation and cache stampede.

Your database is doing the same work a thousand times a second
The one principle behind every cache
What a cached request actually looks like
The four patterns, and what each one costs you
Cache-aside in code
The two hard problems: invalidation and stampede
Where caches live
Common mistakes that cost hours
Takeaways
Where to go next

Your database is doing the same work a thousand times a second

Picture a product page. Every visitor hits the same endpoint, which runs the same query: "give me product 42 and its reviews." The product hasn't changed in three weeks. Yet your database recomputes that answer thousands of times a second, joining tables, scanning indexes, serializing rows, only to hand back the exact same bytes it handed back a millisecond ago.

That is wasted work, and it is the number one reason backends fall over under load. The fix is not a bigger database. The fix is to remember the answer so you don't have to ask again. That's caching, and getting it right is one of the highest-leverage skills a backend engineer can build.

📌 Who this is for: Junior-to-mid backend engineers who keep hearing "just add a cache" and want to actually understand the patterns, the trade-offs, and the foot-guns. You should be comfortable with HTTP requests and a database query. No distributed-systems PhD required.

The one principle behind every cache

A cache is a small, fast copy of data kept close to where it's needed, traded against the risk that the copy goes stale.

The entire field of caching, in one sentence

Everything else, the patterns, the TTLs, the invalidation headaches, flows from that single trade. You gain speed; you risk serving something slightly out of date. The whole craft is deciding how much staleness you can tolerate for how much speed.

In the real world	In tech
The basement archive with every file the company owns	Your database, complete, durable, slow to walk to
The handful of folders you keep on your desk	The cache, tiny, instant to grab, holds only what's hot
Walking to the basement when a file isn't on your desk	A cache miss, fall back to the database, then bring a copy up
A desk folder going out of date after someone edits the master	Stale cache, the hard part: knowing when to throw the copy away

A cache is just keeping the files you use most on your desk.

What a cached request actually looks like

The classic flow is the cache-aside read. Before touching the database, ask the cache. If it has the answer (a hit), serve it. If it doesn't (a miss), fetch from the database, drop a copy in the cache for next time, then serve. Here's that path:

A read with cache-aside: hits skip the database entirely; misses populate the cache on the way back.

Look in the cache first: Build a stable key like product:42 and ask the cache for it. This is a single fast network round-trip to Redis, typically under a millisecond.
On a hit, serve and stop: If the value is there, deserialize it and return. The database never hears about this request. This is the whole point, the hot path costs almost nothing.
On a miss, fall back to the database: The key isn't cached (first request, or it expired). Run the real query against the database to get the authoritative answer.
Populate the cache with a TTL: Write the fresh value back into the cache with an expiry (say, 300 seconds) so the next reader gets a hit. The TTL is your safety net against staleness.
Return to the client: Serve the answer. The first reader paid the full cost; everyone for the next five minutes rides for free.

The four patterns, and what each one costs you

Reads and writes can each route through the cache in different ways. Four patterns dominate. The split that matters most: does your application code manage the cache (cache-aside), or does the cache layer itself sit in front of the database and manage it for you (read-through / write-through / write-behind)?

Pattern	How it works	Trade-off
Cache-aside	App checks cache; on miss, app queries DB and populates the cache itself. App owns the logic.	Simple and flexible, but every reader duplicates the miss logic, and a write must remember to invalidate.
Read-through	App only talks to the cache; the cache loads from the DB on a miss transparently.	Cleaner app code, but you need a cache that supports a loader, and first-read latency still hits the DB.
Write-through	Writes go to the cache and the DB synchronously, in one operation.	Cache is always fresh, but every write pays both write latencies, slower writes for guaranteed consistency.
Write-behind	Writes hit the cache instantly; the cache flushes to the DB asynchronously later.	Blazing-fast writes, but a crash before flush loses data, and the DB is briefly behind reality.

The four core caching patterns. Choose by how much consistency you need and how much write latency you can spend.

For most read-heavy services, cache-aside is the default, it's explicit, easy to reason about, and the cache failing just means slower requests, not broken ones. Reach for write-through when freshness is non-negotiable, and write-behind only when write throughput is the bottleneck and you can tolerate a small window of risk.

Cache-aside in code

Here's the canonical cache-aside read in Python with Redis. Note the three moving parts: a stable key, a TTL on the write, and serialization (Redis stores bytes, not objects).

products.py

import json
import redis

cache = redis.Redis(host="localhost", port=6379, decode_responses=True)
TTL_SECONDS = 300  # 5 minutes, tune to how stale you can tolerate


def get_product(product_id: int) -> dict:
    key = f"product:{product_id}"

    # 1. Ask the cache first
    cached = cache.get(key)
    if cached is not None:
        return json.loads(cached)  # HIT, DB never touched

    # 2. MISS, fall back to the source of truth
    product = db.query_product(product_id)

    # 3. Populate the cache with a TTL so the next reader hits
    cache.set(key, json.dumps(product), ex=TTL_SECONDS)

    return product


def update_product(product_id: int, changes: dict) -> None:
    db.update_product(product_id, changes)
    # Invalidate, don't trust the old copy. Next read re-populates.
    cache.delete(f"product:{product_id}")

The write path is where most bugs live. After updating the database, we delete the cached key rather than trying to overwrite it. Deleting is safer: the next read re-populates from the authoritative source, so you never risk writing a half-built or out-of-order value into the cache.

The two hard problems: invalidation and stampede

There's an old joke that there are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors. The joke is funny because invalidation really is brutal. A cache is a promise that the copy still matches the source, and the moment that promise breaks silently, you're serving wrong data to real users.

Invalidation: knowing when to throw the copy away

You have two tools. TTL (time-to-live) is the lazy, reliable one: every entry self-destructs after N seconds, so staleness is bounded even if you forget everything else. Explicit invalidation is the precise one: when data changes, delete the matching key right then. Real systems use both, a short-ish TTL as a backstop, plus explicit deletes on writes for freshness where it matters.

Stampede: the thundering herd

A cache stampede (or thundering herd) happens when a hot key expires and a thousand concurrent requests all miss at the same instant. They all fall through to the database simultaneously, each running the expensive query the cache was supposed to prevent, and the database, hit with a thousandfold spike, melts. The fix: a short lock so only one request recomputes while the others wait, or staggered TTLs (add a little random jitter) so keys don't all expire on the same tick.

⚠️ A cache is not a database: Caches are allowed to lose data, that's the deal you signed for speed. Never make correctness depend on a value being in the cache. If Redis restarts and forgets everything, your service should get slower, not wrong. Always design the miss path to produce the correct answer on its own.

Where caches live

"The cache" isn't one place. It's a spectrum from closest-and-smallest to farthest-and-biggest, and serious systems layer several:

In-process, a hash map or LRU inside your app's own memory. Nanosecond-fast, zero network, but each server has its own copy (no sharing) and it dies on restart. Great for tiny, hot, rarely-changing data like feature flags.
Distributed (Redis / Memcached), a separate service all your app servers share. One network hop, survives app restarts, and one invalidation reaches everyone. This is the workhorse for cache-aside. Redis adds data structures and persistence; Memcached is leaner and pure key-value.
CDN / edge, caches whole HTTP responses (images, pages, API results) in data centers near the user. The request never reaches your servers at all on a hit. Ideal for public, cacheable content; controlled with Cache-Control headers.

These compose. A request might check an in-process cache, then Redis, then the database, each layer catching what the one before it missed. The closer the layer, the faster and the smaller. Start with one shared Redis; reach for the others when the numbers tell you to.

Common mistakes that cost hours

No TTL. A cache entry with no expiry can outlive its truth forever. If your invalidation has a single bug, you serve that stale value until the heat death of the universe. Always set a TTL as a backstop, even when you also invalidate explicitly.
Caching everything. Caching data that's read once, or changes every second, just adds a network hop and a consistency risk for zero benefit. Cache what's hot and stable, not what's convenient.
Serving stale data silently. Updating the database but forgetting to invalidate the cache is the classic correctness bug. Every write path must either delete or refresh the matching key, make it part of the write, not an afterthought.
Ignoring the thundering herd. A naive cache works fine in dev and stampedes the database the first time a popular key expires under real traffic. Add a lock or TTL jitter to hot keys before they bite you in production.
Trusting the cache for correctness. Treating a cache as durable storage means a Redis restart becomes a data-loss incident. The miss path must always be able to produce the right answer alone.

Takeaways

Caching in nine lines

A cache trades a small risk of staleness for a large win in speed.
Cache-aside is the sensible default: check cache, miss falls back to DB, then populate.
Read-through hides the loader; write-through keeps the cache fresh; write-behind makes writes fast but riskier.
Always set a TTL, it's your backstop when invalidation has a bug.
On writes, delete the key rather than overwriting it; the next read re-populates cleanly.
Cache stampede melts databases, defend hot keys with a lock or TTL jitter.
Caches live in-process, in Redis/Memcached, and at the CDN edge; layer them deliberately.
Cache what's hot and stable, not everything.
Never make correctness depend on the cache, the miss path must stand on its own.

Where to go next

Caching makes reads cheap, but it can't fix a slow query underneath, the first reader and every cache miss still pays that cost. Make the source fast too, and understand how caching fits into scaling the whole system.

Database Indexing & Query Performance, make the miss path itself fast, so a cold cache doesn't hurt.
Scalability Principles, where caching sits among the broader tools for handling load.
Follow the full Backend Engineer track to build these skills in order.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.

DEV Community: Sri Balaji

Core Web Vitals & Frontend Performance

Contents

The site that lied to you

The principle: measure what users feel

The page-load timeline, mapped to the user

The three vitals at a glance

Two fixes that pay for themselves

Lazy-load images you cannot see yet

Code-split so the main thread can breathe

Common mistakes that cost hours

Takeaways

Where to go next

State Management in Frontend Apps

Contents

You wired up a global store for a toggle

Pick the narrowest scope that works

The five kinds of state, by scope

A cheat sheet: state type to tool

Local state vs a server-cache hook in code

Server state is not client state

Common mistakes that cost hours

Takeaways

Where to go next

Rendering Strategies: CSR, SSR, SSG & ISR

Contents

The beautiful app nobody could find

One sentence, then a kitchen

Where the HTML actually comes from

The four strategies, side by side

What this looks like in config

Hydration: the part everyone underestimates

Common mistakes that cost you users

Takeaways

Where to go next

JavaScript for the Browser

Contents

The click that froze a page

One chef, one thread

The picture: how the event loop works

Ordering: sync vs microtask vs macrotask

Events, delegation, and async in real code

Why long tasks block paint

Common mistakes that cost hours

Takeaways

Where to go next

CSS Fundamentals: The Box Model & Layout

Contents

Why won't this div center?

Every element is a box

The box model, layer by layer

Normal flow: what happens before you do anything

Flexbox vs Grid: one dimension or two

Build it: a responsive layout

The cascade & specificity

Common mistakes that cost hours

Takeaways

Where to go next

How the Browser Renders a Page

Contents

You hit Enter, then what?

One sentence, then a picture

The critical rendering path

What happens at each stage, and what slows it down

What blocks rendering

Reflow vs repaint vs composite (and layout thrashing)

Common mistakes that cost hours

Takeaways

Where to go next

What Is a Frontend Engineer?

Contents

You can see the work, and that is the hard part

A one-line definition (and a kitchen)

The browser is the runtime

Frontend vs backend: who owns what

The modern skill set (beyond "just styling")

Common misconceptions

Takeaways

Where to go next

API Design: Evolution & Versioning