Vaibhav Somani

Idempotent Consumers in Event Streams

Sun, 14 Jun 2026 09:30:00 -0400

In any event-driven system, the consumer will eventually receive the same event twice. This is not a bug you can engineer away — it is a structural consequence of how reliable messaging works. Brokers guarantee at-least-once delivery, which means redelivery on uncertain acknowledgments. Producers retry on lost responses. Rebalances replay uncommitted offsets. Network partitions resurrect in-flight messages. The only robust response is to make the consumer tolerate duplicates: to build an idempotent consumer, one whose effect on the world is the same whether it processes an event once or ten times.

Data Pipeline Backpressure Handling

Thu, 11 Jun 2026 15:48:00 -0400

Every data pipeline is a chain of producers and consumers operating at different, time-varying speeds. When an upstream stage produces faster than a downstream stage can consume, work accumulates somewhere. Backpressure is the mechanism by which a slow consumer tells a fast producer to slow down, so that “somewhere” is a bounded, intentional place rather than an unbounded queue that eventually exhausts memory and crashes the process.

Handling backpressure well is the difference between a pipeline that degrades gracefully under load and one that falls over the moment traffic exceeds steady-state capacity. This post covers the failure mode, the strategies for absorbing and propagating pressure, and the trade-offs of each.

Exactly-Once Processing Guarantees

Mon, 08 Jun 2026 13:05:00 -0400

“Exactly-once” is the most misunderstood phrase in distributed systems. Taken literally — every message is delivered and processed precisely one time, no more, no less, under all failures — it is provably impossible in an asynchronous network with crashes. Yet “exactly-once” appears prominently in the marketing of Kafka, Flink, and every modern stream processor. The resolution to this apparent contradiction is the key to understanding the whole topic: what these systems actually provide is exactly-once processing semantics (often called effectively-once), achieved by combining at-least-once delivery with deduplication and atomic state commits — not exactly-once delivery.

Feature Flags with Rollout Strategies

Fri, 05 Jun 2026 10:22:00 -0400

Feature flags decouple deployment from release. Once that decoupling exists, the interesting engineering question stops being “is the code in production?” and becomes “for whom is this code active, and how do we move that population safely from 0% to 100%?” A rollout strategy is the answer to that second question, encoded as data rather than as a redeploy.

This post covers the backend mechanics of feature flagging: flag evaluation models, the common rollout strategies, consistency guarantees, and the operational machinery (kill switches, observability, cleanup) that separates a toy flag library from a production-grade release platform.

Tearing in concurrent UI

Fri, 05 Jun 2026 09:15:00 -0400

Mental model: one screen, two snapshots

Tearing happens when different parts of the UI render from different versions of shared state at the same time. In a concurrent renderer, rendering can be paused, resumed, and interleaved. If an external store changes during that process and components read it unsafely, the committed screen can show an impossible combination.

Imagine a header shows cart count 3 while the checkout panel, rendered from a newer store snapshot, shows four items. Neither component is individually wrong, but the screen is inconsistent.

Service Discovery: Consul vs DNS

Tue, 02 Jun 2026 13:50:00 -0400

The problem service discovery solves

In a static world, service A calls service B at a hardcoded IP and port. In a dynamic world — autoscaling groups, container orchestrators, rolling deploys, spot-instance churn — B’s instances appear and disappear constantly, and their addresses change. Service discovery is the mechanism by which A finds a current, healthy instance of B without anyone editing config.

Every solution must answer three questions:

Registration — how does a new instance announce itself?
Lookup — how does a caller find available instances?
Health — how do dead instances get removed before callers hit them?

DNS-based discovery and Consul represent two ends of a spectrum. DNS leans on a protocol every machine already speaks; Consul is a purpose-built registry with rich health and metadata. Understanding their trade-offs is mostly about understanding what each one cannot do well.

Blue-Green vs Canary Deployments

Sun, 31 May 2026 15:25:00 -0400

Two answers to one question

Every deployment strategy is an answer to the same question: how do you replace running version N with version N+1 without breaking the users hitting your service right now? The naive answer — stop the old, start the new — causes downtime and an all-or-nothing blast radius. Blue-green and canary are the two dominant disciplined alternatives, and they make opposite bets about how to manage risk.

Virtual Memory and Page Faults Impact

Thu, 28 May 2026 16:40:00 -0400

The abstraction every process lives inside

Every process on a modern OS runs inside a private virtual address space. The pointers your program dereferences are virtual addresses; they do not correspond directly to physical RAM. A hardware unit called the MMU, driven by per-process page tables, translates virtual addresses to physical ones at the granularity of a page — typically 4 KiB on x86-64.

This indirection buys a lot: isolation between processes, the ability to over-commit memory, demand paging, copy-on-write, memory-mapped files, and shared libraries that exist once in physical RAM but appear in many address spaces. The cost is that every memory access is potentially a translation, and sometimes that translation reveals the page is not actually resident. That event is a page fault, and understanding its flavors is the key to reasoning about backend performance.

Container Runtime Security: seccomp and AppArmor

Mon, 25 May 2026 11:20:00 -0400

Containers are not a security boundary by default

A container is not a virtual machine. It is a normal Linux process whose view of the system has been narrowed by namespaces (what it can see) and cgroups (what it can use). Crucially, every process in every container talks to the same host kernel. A single exploitable kernel bug reachable through a syscall is a path out of the container.

That shared kernel is why runtime security matters. Namespaces isolate resources; they do not reduce the kernel’s attack surface. The two mechanisms that actually shrink what a container can ask the kernel to do are seccomp (filters which syscalls are allowed) and Linux Security Modules like AppArmor and SELinux (mediate what resources those syscalls may touch). They operate at different layers and are most effective together.

Consistent Hashing for Load Balancing

Fri, 22 May 2026 10:15:00 -0400

Why naive hashing breaks under scaling

The simplest way to distribute keys across a set of N backend nodes is modulo hashing: pick a node with hash(key) % N. It is fast, stateless, and uniform when the hash function is good. The problem appears the moment N changes.

When you add or remove a single node, the divisor in hash(key) % N changes for every key. The mapping is recomputed globally, and the fraction of keys that move is roughly (N-1)/N — almost all of them. For a cache layer this means a near-total cache miss storm; for a sharded database it means a massive rebalancing operation; for sticky sessions it means most users get bounced to a different server.

Sidecar Pattern Limitations

Thu, 21 May 2026 09:05:00 -0400

What the sidecar promises

The sidecar pattern attaches a helper container to a primary application container, sharing the same lifecycle, network namespace, and often storage. The helper handles cross-cutting concerns — TLS termination, retries, metrics, log shipping, secrets injection — so the application can stay ignorant of them. A service mesh like Istio or Linkerd is the most prominent example: every pod gets a proxy sidecar that intercepts all traffic.

Lock-Free Data Structures

Mon, 18 May 2026 13:27:00 -0400

What lock-free actually means

“Lock-free” is one of the most abused terms in concurrent programming. It does not mean “no locks in the code,” and it does not mean “fast.” It is a precise progress guarantee: a data structure is lock-free if, at any point, at least one thread is guaranteed to make progress in a finite number of steps, regardless of what other threads do, even if some of them are suspended mid-operation.

Browser compositing layers

Fri, 15 May 2026 12:35:00 -0400

Layers are an implementation strategy

A browser compositing layer is a rendered surface that can be moved, clipped, transformed, blended, and assembled with other surfaces. Layers let the compositor update parts of the screen without repainting the entire page. They are essential for video, canvas, transforms, opacity animations, fixed elements, and complex scrolling.


graph TD
 DOM["DOM tree"] --> Render["render tree"]
 Render --> Paint["paint chunks/display lists"]
 Paint --> Layerize["layerization heuristics"]
 Layerize --> L1["layer texture: header"]
 Layerize --> L2["layer texture: content tiles"]
 Layerize --> L3["layer texture: modal"]
 L1 --> Composite["compositor frame"]
 L2 --> Composite
 L3 --> Composite

A layer is not the same as a DOM element and not the same as a stacking context, though they are related. The engine groups paint chunks into composited surfaces based on correctness and performance heuristics.

Syscall Overhead and Context Switching

Fri, 15 May 2026 11:05:00 -0400

The hidden tax on every system call

A system call looks like an ordinary function call in your code, but it is anything but. Crossing the boundary from user space into the kernel is one of the more expensive operations a CPU performs in the course of normal work, and a context switch between threads is more expensive still. When you’re chasing tail latency or trying to squeeze throughput out of a hot path, these costs stop being abstract and start showing up in flame graphs.

Bloom Filters and HyperLogLog in Practice

Wed, 13 May 2026 10:51:00 -0400

Trading exactness for scale

Some questions are cheap to answer approximately and ruinously expensive to answer exactly. “Have I seen this item before?” and “How many distinct items have I seen?” are two of them. Answer them exactly and you store every item, which costs memory proportional to the data. Answer them approximately and you can use a fixed, tiny amount of memory regardless of scale, accepting a controlled, quantifiable error.

Scheduler priorities

Tue, 12 May 2026 16:25:00 -0400

Mental model: not all UI work deserves the same lane

Scheduler priorities let a renderer decide which work should run now, which work can wait, and which work should be interrupted. The browser has one main thread for JavaScript, style, layout, paint coordination, and input handling. If a large render monopolizes that thread, a keystroke waits behind work the user may no longer care about.

Concurrent UI systems treat rendering as interruptible work. Typing, clicking, and focus updates should outrank background list filtering, tab preloads, or offscreen rendering. The goal is not to make total work disappear; it is to keep the user-facing work responsive.

epoll and kqueue Internals

Tue, 12 May 2026 14:18:00 -0400

The problem they solve

A server that handles thousands of concurrent connections faces a deceptively simple question: which sockets are ready for I/O right now? The naive answers don’t scale. Spawning a thread per connection drowns the scheduler. Polling each socket in a loop wastes the CPU. The classic readiness syscalls, select and poll, scale linearly with the number of watched descriptors, which collapses under load.

epoll on Linux and kqueue on the BSDs (including macOS) are the scalable answers. Both deliver O(1) readiness notification with respect to the number of idle connections, which is exactly the property you need for the C10K problem and beyond. Understanding how they work internally explains why they’re fast, why edge-triggered mode is tricky, and how to avoid the subtle bugs that bite event-loop authors.

Memory Barriers and CPU Cache Coherence

Sat, 09 May 2026 16:33:00 -0400

When the hardware lies to you

You write code that stores to one variable and then another. You assume the rest of the system sees those stores happen in that order. On a single thread, the CPU guarantees this illusion. Across threads on different cores, the guarantee evaporates. The store you issued first might become visible to another core after the store you issued second. Your program is correct as written and broken as executed.

Zero-Copy Networking with sendfile

Fri, 08 May 2026 09:42:00 -0400

Why copies are the enemy

When a server streams a file to a socket, the naive approach involves a surprising amount of data movement. The bytes don’t travel from disk to network card in a straight line. They bounce through kernel buffers and user-space buffers, get copied multiple times, and force several transitions between user mode and kernel mode. Each copy burns CPU cycles, pollutes the cache, and consumes memory bandwidth that could be doing useful work.

Tree shaking internals

Wed, 06 May 2026 09:00:00 -0400

Tree shaking is dead-code elimination for module graphs. The bundler starts from entry points, follows imports, marks used exports, and drops code it can prove is unused. The phrase sounds simple, but the result depends on module syntax, side effects, package metadata, and how confidently the bundler can reason about execution.


flowchart TD
 Entry[entry module] --> ImportA[import used fn]
 Entry --> ImportB[import component]
 Lib[library module] --> Used[used export]
 Lib --> Unused[unused export]
 ImportA --> Used
 Unused -. dropped if safe .-> Output[final bundle]
 Used --> Output
 ImportB --> Output

Why ESM matters

ES modules have static structure. import { format } from "./date.js" can be analyzed without running the program. CommonJS is dynamic: require() can be conditional, computed, or mixed with runtime mutation. Bundlers can optimize some CommonJS, but ESM gives them much stronger guarantees.

Protobuf vs JSON: Performance Trade-offs

Tue, 05 May 2026 13:36:19 -0400

Picking a Serialization Format Is an Architectural Decision

Every distributed system has to turn in-memory objects into bytes and back — for network calls, queues, caches, and persistence. The format you choose quietly determines your wire size, CPU cost, schema discipline, and debuggability for the life of the system. The two most common choices sit at opposite ends of a spectrum: JSON, a text format optimized for human readability and ubiquity, and Protocol Buffers (Protobuf), a binary format optimized for size and speed.

Offline conflict resolution

Sat, 02 May 2026 12:45:00 -0400

Offline conflict resolution is the set of rules that decides what happens when users make changes without a live connection and those changes meet other changes later. The hard part is not detecting that two writes happened. The hard part is choosing domain-correct semantics: should edits merge, should one win, should the user decide, or should the system create a new version?

The mental model is that offline-first applications have at least two logs: local intent and remote truth. While offline, the app records local operations. On reconnect, it exchanges state with the server, rebases or merges local operations, resolves conflicts, and updates the UI without pretending that every conflict is an error.

API Contract Testing with Pact and Spring Cloud Contract

Sat, 02 May 2026 11:27:48 -0400

The Integration Testing Gap

You have two services: a consumer (say, a web BFF) and a provider (an orders API). How do you guarantee they actually work together? The traditional answer is end-to-end integration tests: spin up both services, plus their databases, plus their dependencies, and exercise real requests. This works until it doesn’t. E2E suites are slow, flaky, expensive to maintain, and they scale combinatorially badly. With N services, the number of integration paths explodes, and a single deployment can require coordinating the whole graph.

Virtual DOM diffing complexity

Sat, 02 May 2026 09:25:00 -0400

Virtual DOM diffing compares a previous tree of UI descriptions with a next tree and computes the host operations needed to update the real UI. The important performance detail is that frameworks do not solve the general tree-edit-distance problem. A fully general diff is too expensive for interactive rendering. Instead, frameworks use heuristics based on element type, position, and keys.


flowchart TD
 A[Previous virtual tree] --> C[Diff]
 B[Next virtual tree] --> C
 C --> D{Same type and key?}
 D -->|yes| E[Update props and children]
 D -->|no| F[Replace subtree]
 E --> G[Commit host operations]
 F --> G

Mental model

A virtual node is a description: type, props, key, and children. During diffing, the renderer asks whether an old node can be reused for a new node. If type and key match, it can update props and continue into children. If they do not match, the old subtree is removed and the new subtree is mounted.

Paint vs composite vs layout

Fri, 01 May 2026 09:45:00 -0400

Rendering work has different prices

When a page changes, the browser does not perform one generic “render” step. It may recalculate style, run layout, paint pixels, raster tiles, and composite layers. Performance work becomes much clearer when you can identify which stage your change invalidates.


flowchart TD
 JS["JS or CSS change"] --> Style["style recalculation"]
 Style --> Layout["layout: compute geometry"]
 Layout --> Paint["paint: record drawing commands"]
 Paint --> Raster["raster: pixels/tiles"]
 Raster --> Composite["composite: assemble layers"]
 Composite --> Screen["display"]
 JS --> CompositeOnly["transform/opacity change"] --> Composite

Layout determines boxes. Paint determines what those boxes look like. Compositing assembles already-rasterized layers onto the screen.

Binary Protocol Parsing

Thu, 30 Apr 2026 10:51:27 -0400

When Text Is Not Enough

Most application developers spend their careers parsing text: JSON bodies, HTTP headers, CSV files. But underneath all of that runs a layer of binary protocols — formats where meaning is encoded in the exact arrangement of bytes rather than human-readable characters. TCP/IP headers, TLS records, MySQL’s wire protocol, Kafka’s protocol, Redis’s RESP, MessagePack, and Protobuf are all binary. If you build network servers, parsers, or high-throughput data pipelines, you eventually have to read bytes directly.

Microservices Observability: Distributed Tracing

Tue, 28 Apr 2026 15:42:11 -0400

The Problem With Logs in a Microservice World

In a monolith, a single request executes inside one process. When something goes wrong you grep one log file, follow the stack trace, and you are done. Decompose that monolith into thirty services and a single user click might fan out across a dozen processes, three message queues, and two databases. The log lines for that one request are now scattered across a dozen machines, interleaved with thousands of other requests, with no thread of continuity between them.

Render waterfalls

Tue, 28 Apr 2026 09:40:00 -0400

Mental model: sequential work hiding in a tree

A render waterfall happens when work that could have run in parallel is discovered sequentially during rendering. Component A renders, starts a fetch, waits, then renders child B, which starts another fetch, waits, then renders child C. The UI may look componentized, but the latency graph is a linked list.

Waterfalls are not limited to network requests. Code splitting, image discovery, font loading, server component fetches, client effects, and even permissions checks can all create sequential dependency chains. The important signal is not “many things loaded”; it is “the next thing could not even be discovered until the previous thing finished.”

Code splitting strategies

Sat, 25 Apr 2026 09:00:00 -0400

Code splitting is a budgeting tool. The question is not “can this code be split?” but “which users need this code, at what moment, and what latency can they tolerate?” A good strategy reduces initial work without turning every interaction into a loading spinner. It is a distribution problem, not a bundler checkbox.


flowchart LR
 App[Application code] --> Critical[critical path]
 App --> Route[route chunks]
 App --> Feature[feature chunks]
 App --> Vendor[vendor chunks]
 App --> Background[background/prefetch]
 Critical --> FCP[fast first interaction]

Mental model

JavaScript cost has multiple parts: download, decompression, parse, compile, and execution. On modern sites, parse and execution can dominate for mid-range devices. Splitting helps when it removes work from the critical path. It does not help if the split code is immediately requested during startup.

Database Failover and Split-Brain Prevention

Fri, 24 Apr 2026 09:14:32 -0400

Why Failover Is Harder Than It Looks

A database failover sounds simple: the primary dies, a replica takes over, traffic resumes. In practice, the operation sits squarely in the middle of one of distributed computing’s nastiest problems. You cannot reliably distinguish a crashed node from a slow or partitioned node. A primary that stopped responding might be dead, or it might be alive on the other side of a network partition still accepting writes. Promote a replica in that second case and you now have two primaries. That condition is called split-brain, and it is the single most dangerous outcome in any high-availability database topology.

Backward-Compatible Schema Evolution

Thu, 23 Apr 2026 17:08:55 -0400

Why Schema Change Is the Hard Part of Backend Work

Writing the first version of a schema is easy. Changing it after millions of rows exist, multiple service versions are deployed, and downtime is unacceptable — that is where backend engineering earns its keep. A careless ALTER TABLE can lock a table for minutes, an incompatible column rename can crash every running instance of the old code, and a dropped field can silently corrupt a consumer three services away.

Chaos Engineering Principles

Wed, 22 Apr 2026 09:25:00 -0400

A distributed system that has never been deliberately broken is a system whose failure behavior is purely theoretical. You wrote retries, timeouts, and fallbacks; you wrote them assuming a model of how dependencies fail; and that model is almost certainly wrong in ways you will only discover at 3 a.m. during a real outage. Chaos engineering inverts this: instead of waiting for production to reveal its weaknesses, you inject controlled failures and find them on your own schedule, with the lights on. This post lays out the discipline — its principles, its experimental method, and how to run it without becoming the outage you were trying to prevent.

Paxos / Raft Consensus Internals

Mon, 20 Apr 2026 11:15:00 -0400

Consensus is the problem of getting a group of unreliable machines to agree on a single value — and to keep agreeing even as some of them crash, restart, and rejoin. It is the foundation under replicated databases, configuration stores like etcd and ZooKeeper, and leader election everywhere. Two algorithms dominate the conversation: Paxos, the theoretical bedrock, and Raft, the version designed to actually be understandable. This post walks through what they guarantee, how each one works mechanically, and why Raft replaced Paxos in most engineers’ heads.

First Input Delay (FID)

Sun, 19 Apr 2026 09:35:00 -0400

First Input Delay measures the delay between a user’s first interaction and the browser’s ability to start running the corresponding event handler. It focuses on input delay, not handler execution or paint. Even though Interaction to Next Paint is now the broader responsiveness metric, FID remains a useful concept because the first interaction is often where users discover that a page only looked ready.

The mental model: FID is main-thread availability at the moment of first input. If JavaScript parsing, execution, hydration, style work, or a third-party script owns the main thread, the browser queues the input until that task finishes.

Structural sharing

Sat, 18 Apr 2026 10:15:00 -0400

Structural sharing is the technique of creating a new version of a data structure by copying only the parts that changed and reusing the rest. It is the performance backbone of practical immutability. Without structural sharing, immutable updates would require copying entire trees, arrays, or maps for every small change.


flowchart TD
 A[Old root] --> B[Old left branch]
 A --> C[Old right branch]
 C --> F[Old leaf]
 D[New root] --> B
 D --> E[New right branch]
 E --> G[New changed leaf]

Mental model

Imagine state as a graph of references. An update creates a new path from the root to the changed leaf. Nodes outside that path are reused. Consumers comparing references can quickly know whether their branch changed. Old versions remain usable because reused nodes are not mutated.

CRDT basics for collaboration

Sat, 18 Apr 2026 09:00:00 -0400

CRDTs are data structures designed so replicas can accept local changes independently, exchange updates later, and converge without a central conflict resolver. In frontend collaboration, that means a user can type, move a card, toggle a checkbox, or edit metadata while disconnected, then sync with other clients without losing concurrent work. The tradeoff is that the conflict policy moves into the data type itself.

The mental model is convergence by construction. A CRDT does not avoid conflicts by preventing concurrent edits. It defines merge behavior so concurrent edits have deterministic meaning.

Byzantine Fault Tolerance Basics

Fri, 17 Apr 2026 13:50:00 -0400

Most distributed systems assume failures are honest: a node either works correctly or it crashes and stops. Byzantine fault tolerance throws out that comfortable assumption. A Byzantine node can do anything — send different messages to different peers, lie about its state, forge data, collude with other bad nodes, or simply behave arbitrarily because of a bug, a memory corruption, or an attacker. Tolerating that is dramatically harder than tolerating a crash, and the math reflects it. This post explains where the famous 3f + 1 bound comes from, how PBFT achieves agreement, and when this expensive machinery is actually worth it.

GPU acceleration in CSS

Thu, 16 Apr 2026 15:25:00 -0400

The GPU is not a magic fast path

“Use GPU acceleration” usually means “make the browser animate by compositing existing layers instead of repainting pixels on the CPU.” The GPU is good at moving textured rectangles, blending opacity, and applying transforms. It is not a general cure for expensive layout, slow JavaScript, huge paints, or memory pressure.


flowchart LR
 DOM["DOM/CSS changes"] --> Layout["layout"]
 Layout --> Paint["paint display lists"]
 Paint --> Raster["raster tiles"]
 Raster --> Layers["GPU textures/layers"]
 Layers --> Composite["transform/opacity compositing"]
 Composite --> Screen["screen"]

The key distinction: animating transform or opacity can often skip layout and paint after the layer has been rasterized. Animating width, top, box-shadow, filter, or background-position may require layout or paint every frame.

Hydration

Thu, 16 Apr 2026 10:50:00 -0400

Mental model: make server HTML interactive without replacing it

Hydration is the client-side process that takes server-rendered HTML and attaches the JavaScript component model to it. The browser already has DOM nodes on screen. The framework recreates enough of the component tree to connect state, event handlers, refs, and effects to those existing nodes.

The key constraint is that the client render must agree with the server output. If the first client render produces different markup, the framework may warn, patch, discard nodes, or remount a subtree. Hydration is fastest and safest when the server and client produce the same initial tree.

Idempotency Keys in API Design

Wed, 15 Apr 2026 10:45:00 -0400

Networks fail in the most inconvenient way possible: not by losing the request, but by losing the response. The client sends “charge this card $50,” the server charges it, and then the acknowledgment vanishes into a dropped connection. The client, seeing no answer, retries. Without protection, the customer is charged twice. Idempotency keys are the standard, battle-tested mechanism for making “retry safely” a first-class property of your API. This post covers what they guarantee, how to implement them correctly, and the subtle failure modes that trip up most first attempts.

Suspense boundaries

Tue, 14 Apr 2026 14:35:00 -0400

Mental model: a boundary is a latency contract

A Suspense boundary defines what part of the UI may wait and what the user sees while it waits. It is not just a spinner wrapper. It is a latency contract between rendering, data fetching, code loading, and user perception.

Good boundaries preserve the page’s structure while slow regions resolve. Bad boundaries blank out too much UI, flicker on fast requests, or hide the source of slowness behind generic loading states.

Dynamic import chunking

Tue, 14 Apr 2026 09:00:00 -0400

Dynamic import() is both a language feature and a bundler signal. In application code it means “load this module asynchronously.” In a bundled frontend it usually means “create a separate chunk boundary here.” Used well, it keeps initial JavaScript small and delays rarely used code. Used casually, it creates a waterfall of tiny chunks that slow down real navigation.


flowchart TD
 Entry[entry chunk] --> Router[router]
 Router -->|import()| Admin[admin chunk]
 Router -->|import()| Editor[editor chunk]
 Editor -->|import()| Markdown[markdown parser chunk]
 Editor -->|import()| Syntax[syntax highlighter chunk]

Internals that matter

Bundlers build a module graph. Static imports become part of the synchronous graph for an entry point. Dynamic imports become async edges. The bundler emits a runtime loader that fetches the referenced chunk when execution reaches that import.

Cache invalidation strategies

Mon, 13 Apr 2026 14:35:00 -0400

Mental model

Cache invalidation is the discipline of making cached data stop being used when it no longer matches the source of truth. The hard part is not deleting entries; it is knowing which entries are affected, how quickly they must disappear, and what happens while different layers disagree.

Frontend systems usually have several caches at once: browser HTTP cache, service worker cache, CDN cache, in-memory data library cache, normalized entity cache, and sometimes local storage or IndexedDB. A mutation may need to update more than one.

Eventual Consistency in Cache

Sat, 11 Apr 2026 14:20:00 -0400

A cache exists to answer a read faster than the source of truth can. The moment you place a copy of data somewhere other than its authoritative home, you create the possibility that the copy and the source disagree. Eventual consistency is the honest name for the contract most caches actually offer: reads may return stale data for some window, but if writes stop, all replicas converge to the same value within a bounded time. This post digs into why that window exists, how to reason about it, and how to keep it small enough that your users never notice.

Optimistic Locking with Version Vectors

Thu, 09 Apr 2026 16:30:00 -0400

Two users open the same record, both edit it, both save. Whose change wins? In a single-database world, optimistic locking with a simple version counter answers this cleanly: the second save is rejected because the row changed underneath it. But once data lives on multiple replicas that accept writes independently, a scalar version number is no longer enough to tell “this is a stale overwrite” apart from “these two edits happened concurrently on different nodes.” Version vectors are the data structure that restores that distinction. This post builds up from the single-node case to version vectors and shows exactly when and why you need them.

Interaction to Next Paint (INP)

Thu, 09 Apr 2026 16:00:00 -0400

Interaction to Next Paint measures page responsiveness across real user interactions. It observes clicks, taps, and keyboard interactions, then reports a high-percentile interaction latency for the page. Unlike older first-input metrics, INP cares about the whole session. A page can load quickly and still fail INP if later interactions are blocked by JavaScript, rendering, or main-thread contention.

The useful mental model splits one interaction into input delay, processing duration, and presentation delay.

Distributed Cache Invalidation: Cache-Aside vs Write-Through

Tue, 07 Apr 2026 16:44:18 -0400

There are only two hard things in computer science, the joke goes, and cache invalidation is one of them. The reason it’s hard is that a cache is a deliberate copy of data that lives somewhere else, and the moment the source of truth changes, your copy is a lie until you do something about it. The strategy you choose — cache-aside, write-through, write-behind — determines who keeps the copy honest, when, and what happens in the window where they disagree. This post dissects the major patterns, their consistency guarantees, and the race conditions that make distributed caching genuinely treacherous.

Immutable data patterns

Tue, 07 Apr 2026 09:40:00 -0400

Immutable data patterns update state by creating new values instead of modifying existing values in place. The goal is not aesthetic purity. The goal is reliable change detection, predictable debugging, safe undo/redo, and fewer hidden side effects between components that share references.


flowchart TD
 A[Previous state] --> B[Update action]
 B --> C[Copy changed path]
 C --> D[Reuse unchanged branches]
 D --> E[Next state]
 A --> F[History/debug snapshot remains valid]

Mental model

State is a value, not a bag of objects to mutate from anywhere. An update receives the previous value and returns the next value. Consumers can compare references to know which branches changed. Old snapshots remain meaningful because later updates do not rewrite them.

Stale-while-revalidate

Mon, 06 Apr 2026 10:10:00 -0400

Mental model

stale-while-revalidate serves a cached response immediately while a refresh happens in the background. The user gets low latency, and the cache eventually catches up. It is a deliberate trade: accept bounded staleness to improve responsiveness.

The pattern exists in HTTP cache directives, service workers, CDNs, and client data libraries. The same question applies everywhere: “How stale is acceptable for this resource?”


sequenceDiagram
 participant U as User
 participant C as Cache
 participant S as Server
 U->>C: Request resource
 C-->>U: Return stale cached response immediately
 C->>S: Revalidate in background
 alt changed
 S-->>C: 200 new body
 C->>C: Update cache
 else unchanged
 S-->>C: 304
 C->>C: Extend cached metadata
 end

Internals that matter

HTTP expresses the pattern like this:

API Gateway Throttling & Caching Layers

Sun, 05 Apr 2026 13:21:36 -0400

An API gateway is the front door to your backend, and the two responsibilities that most determine whether that door holds up under load are throttling and caching. Throttling protects your services from being overwhelmed; caching prevents them from doing the same work twice. Done well, the gateway absorbs traffic that would otherwise flatten your origin. Done badly, it either lets a stampede through or serves stale, incorrect data to every client. This post examines the algorithms behind gateway throttling, where caching belongs in the request path, and how the two interact.

WebRTC

Sat, 04 Apr 2026 14:30:00 -0400

WebRTC is the browser stack for peer-to-peer audio, video, and data channels. The API looks like media elements and event handlers, but the system underneath includes signaling, ICE candidate gathering, NAT traversal, DTLS, SRTP, congestion control, codecs, jitter buffers, and device permissions. Practical WebRTC work is mostly about managing that state machine reliably.

The first mental model: WebRTC does not define signaling. Your app must exchange offers, answers, and ICE candidates over a separate channel such as WebSocket, HTTP polling, or your realtime backend. WebRTC uses that information to establish media and data paths.

Module federation

Fri, 03 Apr 2026 09:00:00 -0400

Module Federation lets one JavaScript build load modules from another build at runtime. It is often used for micro-frontends, but the underlying idea is simpler: split deployment ownership without publishing every shared piece as an npm package. A host application discovers a remote container, asks for an exposed module, and executes it with a shared dependency scope.


flowchart LR
 Host[Host app] -->|loads remoteEntry.js| Remote[Remote container]
 Host --> Share[Shared scope]
 Remote --> Share
 Remote --> Exposed[./Widget module]
 Host -->|render| Exposed

Mental model

At build time, the remote declares which modules it exposes. The host declares remotes it may consume. At runtime, the host loads the remote entry script, initializes dependency sharing, then imports exposed modules. This means integration failures can happen after deploy even when both projects compiled successfully.

Service Mesh Traffic Shifting

Thu, 02 Apr 2026 15:38:47 -0400

Traffic shifting is the capability that turns a service mesh from a fancy observability layer into a genuine deployment safety net. It lets you route a controlled fraction of requests to a new version, watch the metrics, and either ramp up or roll back — all without redeploying, without DNS changes, and without touching your application code. This post covers how traffic shifting works at the sidecar level, the difference between weight-based and request-based routing, how canary analysis automates the decision, and the failure modes that silently corrupt a rollout.

Partial hydration

Thu, 02 Apr 2026 14:10:00 -0400

Mental model: hydrate less of what you already rendered

Partial hydration is the practice of server-rendering a page while hydrating only the parts that need client-side behavior. The HTML can contain a full page, but the browser does not have to download, parse, execute, and attach listeners for every component that produced it.

This differs from classic full-app hydration, where the client framework rebuilds a matching component tree for the whole page. Partial hydration asks a sharper question: which rendered regions actually need to become live?

CSS containment

Thu, 02 Apr 2026 10:05:00 -0400

Containment gives the browser boundaries

CSS containment lets an element promise that some of its internals do not affect the outside world. That promise helps the browser limit style recalculation, layout, paint invalidation, and size dependency. In large interfaces, containment is one of the few CSS tools that directly changes how much of the rendering tree must be reconsidered.


graph TD
 Change["change inside component"] --> Style["style containment limits selector effects"]
 Change --> Layout["layout containment limits geometry effects"]
 Change --> Paint["paint containment clips invalidation"]
 Change --> Size["size containment removes intrinsic contribution"]
 Style --> Faster["smaller rendering work"]
 Layout --> Faster
 Paint --> Faster
 Size --> Faster

The property is contain, with values like layout, paint, style, size, content, and strict.

Background Job Queues (Celery / BullMQ) Retry Semantics

Wed, 01 Apr 2026 10:07:55 -0400

Background job queues are where the optimistic assumptions of synchronous code go to die. A job runs in a worker that can crash, against a network that can partition, talking to services that can time out. The entire value proposition of a queue is that it will try again when things fail — but “try again” hides a thicket of decisions: how many times, with what delay, whether the retry might run the job twice, and what happens to jobs that never succeed. This post compares how Celery and BullMQ handle retries, the semantics you must understand to avoid corrupting data, and the patterns that keep a queue healthy under failure.

Selective hydration

Wed, 01 Apr 2026 10:05:00 -0400

Mental model: hydration is scheduling, not just attaching events

Hydration turns server-rendered HTML into an interactive client tree. Selective hydration means the browser does not hydrate the entire page with one equal-priority pass. It can prioritize the parts the user needs first, often driven by Suspense boundaries, user input, visibility, and resource readiness.

This matters because SSR can improve first paint while still leaving the page unusable during a large hydration task. Selective hydration attacks that gap. The goal is not merely a pretty static page; it is a page where the first meaningful interaction is not blocked by unrelated widgets.

Serverless Cold-Start Mitigation

Sun, 29 Mar 2026 11:52:09 -0400

Cold starts are the tax you pay for not running servers. The first invocation of a function that has no warm container behind it must wait for the platform to allocate compute, download your code, bootstrap the runtime, and initialize your application before a single line of handler logic executes. For a latency-sensitive API this can turn a 20ms p50 into a 2-second p99, and the worst part is that it happens unpredictably. This post breaks down exactly what a cold start consists of, which phases you can influence, and the concrete techniques that actually move the needle.

Cumulative Layout Shift (CLS)

Sat, 28 Mar 2026 12:25:00 -0400

Cumulative Layout Shift measures unexpected visual movement. It is not a general animation metric. It penalizes layout shifts that occur without recent user input and that move visible content. CLS is frustrating because it breaks spatial memory: the user reaches for a button, content jumps, and the click lands somewhere else.

The mental model is reservation. Any content that will appear later needs space before it arrives, or it needs to appear in a layer that does not push existing content. Images, ads, embeds, banners, fonts, client-rendered widgets, and personalized modules are the usual sources.

Kubernetes Pod Disruption Budgets

Fri, 27 Mar 2026 09:14:22 -0400

Pod Disruption Budgets (PDBs) are one of the most misunderstood reliability primitives in Kubernetes. They sit quietly in your manifests until the day a node drain takes down half your fleet, and only then do most teams discover what they were supposed to be protecting against. This post digs into how PDBs actually work, the difference between voluntary and involuntary disruptions, the arithmetic behind minAvailable and maxUnavailable, and the failure modes that bite production clusters.

Referential equality

Wed, 25 Mar 2026 08:55:00 -0500

Referential equality means two values are considered equal because they point to the same object, array, or function instance. In JavaScript, objects compare by reference with ===. Two objects with identical fields are not equal unless they are the same allocation. Frontend frameworks lean on this rule because it makes change detection cheap: if a reference did not change, many systems assume the value did not change.


flowchart TD
 A[Previous prop object] --> C{Same reference?}
 B[Next prop object] --> C
 C -->|yes| D[Can skip shallow update]
 C -->|no| E[Inspect or rerender]

Mental model

Referential equality is a signal. A new reference usually means “something may have changed.” The same reference usually means “nothing changed.” The signal works when data is immutable and updates create new objects along changed paths. It fails when code mutates objects in place or recreates objects unnecessarily.

Index Bloat and Vacuum Strategies

Mon, 23 Mar 2026 15:52:00 -0400

Why bloat exists at all

To understand index bloat you first have to understand a design decision at the heart of PostgreSQL: MVCC, multi-version concurrency control. PostgreSQL never updates a row in place. An UPDATE writes a new version of the row and marks the old version as obsolete but does not remove it. A DELETE just marks the row dead. The old versions — dead tuples — stick around so that transactions which started before the change can still see the version they’re entitled to. This is what lets readers never block writers.

ETag vs Cache-Control

Mon, 23 Mar 2026 11:45:00 -0400

Mental model

Cache-Control tells caches how long and under what rules a response can be reused. ETag gives caches a validator they can send back to ask, “Is my stored response still current?” They are complementary, not alternatives.

Freshness avoids a network round trip. Validation makes a round trip but can avoid downloading the full response. The fastest request is the one never made; the next best is a 304 Not Modified.

Backpressure in streams API

Mon, 23 Mar 2026 10:05:00 -0400

Backpressure is the mechanism that prevents a fast producer from overwhelming a slow consumer. In the browser Streams API, it is the difference between a pipeline that stays bounded and a pipeline that quietly buffers unbounded data until memory, latency, or responsiveness collapses. If you stream fetch responses, generate client-side exports, transform large files, or bridge WebSockets into streams, you need to understand where pressure is applied.

The mental model is a queue with a desired size. A ReadableStream has an internal queue. A consumer reads from it. A producer enqueues into it. When the queue reaches its high water mark, controller.desiredSize becomes zero or negative, and a well-behaved producer slows down.

Shadow DOM

Mon, 23 Mar 2026 09:00:00 -0400

Shadow DOM is an encapsulation boundary for DOM and CSS. It lets a component own internal markup without leaking every class name into the page, and without page styles accidentally rewriting its internals. The tradeoff is that styling, events, accessibility, and testing must be designed around the boundary instead of pretending it is normal nested HTML.


flowchart TD
 Host[custom-element host]
 Host --> Light[Light DOM children]
 Host --> ShadowRoot[Shadow root]
 ShadowRoot --> Internal[Internal DOM]
 ShadowRoot --> Slot[slot]
 Light -->|assigned nodes| Slot
 PageCSS[Page CSS] -. limited .-> Host
 ComponentCSS[Shadow CSS] --> Internal

Mental model

A shadow root is attached to a host element with attachShadow({ mode: "open" }) or closed. The component renders internal DOM inside that root. Selectors in the page do not cross into the shadow tree, and selectors inside the shadow tree do not target the rest of the page. This gives component authors a local styling environment.

Prepared Statement Caching

Fri, 20 Mar 2026 10:14:00 -0400

What a prepared statement actually buys you

Every SQL query the database receives goes through a pipeline before a single row is touched: it is parsed into a syntax tree, analyzed and rewritten (resolving table and column names, expanding views), and then planned — the optimizer enumerates join orders, index choices, and scan strategies and picks the cheapest. Only then does execution begin.

For a trivial point lookup, this planning overhead can rival or exceed the execution itself. If you run the same query shape thousands of times per second, re-parsing and re-planning each time is pure waste.

Islands architecture

Thu, 19 Mar 2026 09:45:00 -0400

Mental model: static HTML with targeted interactivity

Islands architecture starts from the assumption that most of a page can be delivered as inert HTML. Only specific interactive regions, or islands, receive client JavaScript. Instead of hydrating one large application root, the page contains multiple independent interactive mounts embedded in server-rendered or statically generated markup.

This model fits content-heavy sites, ecommerce pages, documentation, marketing pages, and dashboards with isolated widgets. The performance win comes from avoiding JavaScript for regions that do not need browser-side state.

Largest Contentful Paint (LCP)

Wed, 18 Mar 2026 14:40:00 -0400

Largest Contentful Paint measures when the largest visible content element in the viewport is painted. It is a user-centric proxy for “the main thing loaded.” The LCP candidate is often a hero image, poster image, heading, large paragraph, or background image discovered through CSS. Optimizing it requires working backward from the actual winning element, not applying generic performance tricks.

Think of LCP as four segments: time to first byte, resource load delay, resource load duration, and element render delay. The slowest segment determines the practical fix.

Subpixel rendering

Wed, 18 Mar 2026 13:40:00 -0400

CSS pixels are not device pixels

Modern layout is full of fractions. CSS pixels are an abstract unit; device pixels are physical display samples. Device pixel ratio, zoom, transforms, percentage layouts, font metrics, and flex/grid distribution all create subpixel values. The browser does not simply round every box to an integer at layout time. It carries fractional geometry forward and resolves it during painting and compositing.


flowchart LR
 CSS["CSS values: %, rem, vw"] --> Layout["fractional layout boxes"]
 Layout --> Paint["paint commands with floats"]
 Paint --> Raster["rasterize to device pixels"]
 Raster --> Composite["composite transformed layers"]
 Composite --> Display["physical pixels"]

Subpixel rendering is why a three-column layout can divide 1000px into thirds without leaving a giant gap. It is also why borders blur, hairlines disappear, and screenshots differ across zoom levels.

Database Connection Pool Exhaustion

Wed, 18 Mar 2026 13:37:00 -0400

A failure that looks like everything else

Connection pool exhaustion is one of the most common production incidents, and one of the most misdiagnosed. The symptom is generic: requests pile up, latency climbs, the application starts returning timeouts or 500s. The database itself looks healthy — low CPU, plenty of memory, queries running fast. Engineers chase slow queries and missing indexes for hours while the real problem is that the application has run out of connections to send those fast queries through.

Server components

Mon, 16 Mar 2026 12:10:00 -0400

Mental model: components can be a transport boundary

Server Components move part of the component tree to the server. The important shift is that a component is no longer only a client-side rendering unit; it can also be a server-side data access and serialization unit. Server Components fetch data, render to a serializable payload, and hand client components only the props needed for interactivity.

This is different from traditional SSR. SSR produces HTML for the first load and then the client app hydrates. Server Components can continue to render on the server across navigations, reducing client JavaScript for non-interactive parts of the tree.

Read Replicas Lag Monitoring

Mon, 16 Mar 2026 11:05:00 -0400

The promise and the catch

Read replicas are the standard first move for scaling reads. You point writes at a primary, stream its changes to one or more replicas, and fan out read traffic across them. Storage stays in sync automatically, and you get more read capacity by adding nodes.

The catch is that replication is asynchronous by default. A replica is always some amount of time behind the primary. That gap is replication lag, and it is the single most important thing to monitor about a replicated system. Lag is invisible when small and catastrophic when large: a user updates their profile, the read hits a lagging replica, and they see their old data. Worse, an order is written and a downstream job reads from a replica that hasn’t caught up, so the order “doesn’t exist” yet.

HTTP/3 and QUIC

Mon, 16 Mar 2026 10:30:00 -0400

Mental model

HTTP/3 is HTTP semantics running over QUIC instead of TCP. QUIC is a UDP-based transport that includes encryption, streams, congestion control, loss recovery, and connection migration. For frontend engineers, the practical promise is lower latency under packet loss and faster connection setup, especially on mobile networks.

HTTP/2 multiplexes many requests over one TCP connection, but TCP still delivers bytes in order. If one packet is lost, all streams sharing that connection can stall until the missing TCP segment is retransmitted. QUIC moves ordering to independent streams, so packet loss blocks only affected streams.

Sharding Strategies and Hot Partition Avoidance

Sat, 14 Mar 2026 16:48:00 -0400

Why shard at all

A single database node has a ceiling. Eventually the working set no longer fits in memory, write throughput saturates a single disk, or the table grows so large that index maintenance and vacuum become unmanageable. Vertical scaling — bigger boxes — buys time but ends at the largest instance your provider sells, and at a price that grows faster than the capacity.

Sharding is horizontal partitioning of data across multiple independent nodes, each owning a disjoint subset of rows. Done well, it gives near-linear scaling of both storage and throughput. Done badly, it concentrates load on one unlucky node — a hot partition — and you get all the operational complexity of a distributed system with none of the scaling benefit.

Memoization pitfalls

Fri, 13 Mar 2026 09:50:00 -0500

Memoization caches the result of a computation for a set of inputs. In frontend code it can reduce expensive derived data, stabilize references passed to children, and avoid repeated work during render. It can also hide stale data, increase memory use, make profiling harder, and create the illusion that a render problem has been solved when the real issue is still there.


flowchart TD
 A[Inputs] --> B{Same as cache key?}
 B -->|yes| C[Return cached value]
 B -->|no| D[Run computation]
 D --> E[Store result]
 E --> C

Mental model

Memoization is a trade: pay comparison and cache complexity to avoid recomputation. It only helps when the saved computation is more expensive than the cache overhead and when input identity changes less often than renders. If the inputs are always new objects, the cache misses every time. If the computation is cheap, the memo wrapper may cost more than recalculating.

AbortController

Thu, 12 Mar 2026 15:25:00 -0400

AbortController is the web platform’s shared cancellation primitive. It started as the cancellation mechanism for fetch, but it now appears across event listeners, streams, timers in some runtimes, and many library APIs. Its value is not just stopping network requests. It gives frontend code a consistent way to model ownership: when a component, route, interaction, or operation ends, everything attached to its signal should stop.

The mental model has two pieces. An AbortController owns an AbortSignal. Consumers receive the signal. When the owner calls abort(), the signal flips to aborted, stores a reason, and notifies listeners exactly once.

Outbox Pattern for Reliable Events

Thu, 12 Mar 2026 09:22:00 -0400

The dual-write problem

Almost every service that owns data also needs to tell the rest of the system when that data changes. An order service writes a row to its orders table and then publishes an OrderPlaced event to Kafka. On paper this is two lines of code. In production it is one of the most common sources of silent data loss in distributed systems.

The trouble is that a database transaction and a message broker publish are two independent systems with two independent commit protocols. There is no shared transaction across them. So you are forced into a sequence:

Custom Elements lifecycle

Thu, 12 Mar 2026 09:00:00 -0400

Custom elements are classes that the browser upgrades into real DOM behavior. Their lifecycle is not a framework lifecycle with a virtual tree in front of it. It is the platform telling your element when it is constructed, connected, disconnected, adopted into another document, or affected by observed attribute changes. That makes the lifecycle precise, but also unforgiving: your element can be created by the parser, by document.createElement, by cloning, or by a framework that moves DOM around during reconciliation.

CQRS and Event Sourcing Projections

Tue, 10 Mar 2026 16:53:00 -0400

Most applications use a single data model for both writing and reading: the same tables, the same objects, the same schema serve commands that change data and queries that fetch it. This works until the demands of writes and reads diverge so much that one model can’t serve both well. CQRS (Command Query Responsibility Segregation) splits them apart. Paired with event sourcing, it produces a powerful architecture where the write side records facts and the read side builds whatever views it needs through projections. This post focuses on that last, often-underexplained piece: how projections turn an event stream into queryable read models, and the hard problems that come with them.

Priority hints

Mon, 09 Mar 2026 15:05:00 -0400

Mental model

Priority Hints let developers nudge the browser’s internal fetch priority using fetchpriority. They are useful when the browser’s default guess is wrong: a hero image should load sooner, or a below-the-fold image should stop competing with critical CSS and JavaScript.

This is a hint, not a command. The browser still considers resource type, render blocking, viewport, connection state, and its own scheduler.


graph TD
 A["HTML parser discovers resources"] --> B["Browser assigns default priority"]
 B --> C{"fetchpriority present?"}
 C -->|high| D["Boost relative priority"]
 C -->|low| E["Deprioritize relative priority"]
 C -->|auto| F["Keep browser default"]
 D --> G["Network scheduler"]
 E --> G
 F --> G

Internals that matter

Browsers already prioritize resources. CSS and blocking scripts are high. Images often start lower until layout reveals whether they matter. That can delay the Largest Contentful Paint image, especially when it appears in the initial viewport but is discovered among many other images.

Thread Pools vs Virtual Threads (Project Loom)

Sun, 08 Mar 2026 11:27:00 -0400

For two decades, the standard advice for writing scalable Java servers has been: never block a thread, because threads are expensive, so wrap everything in thread pools and reactive callbacks. Project Loom’s virtual threads, now a stable feature of the JVM, upend that advice. They make blocking cheap again, letting you write straightforward synchronous code that scales to millions of concurrent operations. This post explains what changed, how virtual threads work under the hood, and when you should still reach for a classic thread pool.

Speculative prerendering

Sun, 08 Mar 2026 10:05:00 -0400

Speculative prerendering loads and renders a likely future page before the user navigates to it. When the prediction is right, navigation can feel instant because HTML parsing, subresource loading, script execution, layout, and sometimes rendering have already happened in a hidden context. When the prediction is wrong, you have spent bandwidth, CPU, memory, cache capacity, and possibly backend quota for no user-visible result.

The mental model is a pipeline: predict intent, declare safe candidates, let the browser prerender under constraints, then activate or discard. Your application must be safe to run before visible navigation.

Log Aggregation with Sampling

Fri, 06 Mar 2026 16:18:00 -0400

Why aggregate, and why sample

A single modern service can emit tens of thousands of log lines per second. Multiply that across a fleet of hundreds of instances and you are producing terabytes per day. Log aggregation is the practice of shipping all of that from individual machines into a central store — Loki, Elasticsearch, a cloud log service — where it can be searched, correlated, and retained. The aggregation part is well understood. The harder question is economic: do you actually need to store every line?

Streaming SSR

Thu, 05 Mar 2026 12:05:00 -0500

Mental model: send the shell before every dependency is done

Traditional server-side rendering waits until the whole page’s data and HTML are ready, then sends one response. Streaming SSR sends useful HTML as soon as possible, then streams later chunks when slower work completes. The user can receive the document shell, critical layout, and fallbacks before every panel is ready.

Streaming is not just “flush earlier.” It changes how you model latency. Parts of the page become independently deliverable regions, often aligned with Suspense boundaries. The server can reveal fast content immediately and let slow content arrive later without blocking the entire first byte.

IntersectionObserver internals

Wed, 04 Mar 2026 16:10:00 -0500

IntersectionObserver answers a geometry question asynchronously

IntersectionObserver tells you when a target intersects a root rectangle. It is built for lazy loading, infinite scrolling, ad visibility, analytics, and scroll-linked activation without running a scroll handler on every frame. The key is that it is asynchronous: the browser computes intersections during its rendering pipeline and delivers entries later.


graph TD
 Root["root viewport or scroll container"] --> RootMargin["apply rootMargin"]
 Target["target border box"] --> Clip["clip through ancestors"]
 RootMargin --> Intersect["intersection rectangle"]
 Clip --> Intersect
 Intersect --> Ratio["intersectionRatio thresholds"]
 Ratio --> Callback["queued observer callback"]

This is why it scales better than manually calling getBoundingClientRect() in scroll events. The engine already has layout and clipping information; the observer lets it batch work.

Garbage Collection Tuning: G1 vs ZGC

Wed, 04 Mar 2026 15:42:00 -0400

Garbage collection is the JVM feature most developers ignore until a production incident forces them to care. A service that hums along at p50 latency of 5ms can suddenly spike to 800ms because a stop-the-world pause froze every thread to reclaim memory. Choosing and tuning the right collector is one of the highest-leverage things you can do for a latency-sensitive Java service. This post compares the two collectors that matter most for modern server workloads: G1 (the default since Java 9) and ZGC (the low-latency contender that went production-ready and non-generational in newer releases).

Stale closure problem

Wed, 04 Mar 2026 10:05:00 -0500

The stale closure problem occurs when a function keeps references to values from an old render, old state transition, or old lexical scope and then runs later as if those values were current. In frontend code it appears in timers, event listeners, promises, subscriptions, memoized callbacks, and effects. The bug is not that closures are broken. The bug is that the callback’s lifetime is longer than the state snapshot it captured.

Streaming fetch response handling

Tue, 03 Mar 2026 09:55:00 -0500

Streaming fetch response handling lets a page process bytes as they arrive instead of waiting for the entire response body. That changes the user experience for large payloads, AI responses, logs, exports, media metadata, and progressive data formats. It also changes failure handling: once you process partial data, you need explicit rules for incomplete messages, cancellation, decoding, and backpressure.

The mental model is that fetch() resolves when response headers are available, not when the body is fully downloaded. The Response.body is a ReadableStream<Uint8Array>. You consume chunks from that stream, decode bytes into text if needed, parse message boundaries, and update UI incrementally.

Preload vs Prefetch vs Preconnect

Mon, 02 Mar 2026 09:50:00 -0500

Mental model

preload, prefetch, and preconnect are resource hints, but they solve different timing problems. preload says “this resource is needed for the current navigation; start it earlier.” prefetch says “this may be needed for a future navigation; fetch it when idle.” preconnect says “I will need this origin soon; warm up DNS, TCP, and TLS.”

Choosing the wrong hint can make performance worse by stealing bandwidth from critical resources.

Message-Driven Architecture with Akka and Orleans

Mon, 02 Mar 2026 10:35:00 -0400

When a system grows beyond a single machine, the comfortable abstractions of in-process method calls break down. Networks fail, machines crash, and latency becomes unpredictable. Message-driven architecture embraces these realities instead of hiding them, treating asynchronous messages as the primary unit of interaction. Two of the most influential frameworks in this space, Akka on the JVM and Orleans on .NET, both build on the actor model but make strikingly different choices about how much complexity the developer should manage. Comparing them illuminates the whole design space of distributed message-driven systems.

Edge rendering

Mon, 02 Mar 2026 08:50:00 -0500

Mental model: move the first decision closer to the user

Edge rendering runs request-time rendering logic in geographically distributed runtimes near the user. The goal is not simply “server-side rendering, but cooler.” The goal is to reduce latency for decisions that must happen before the first byte: locale, authentication hints, experiments, personalization, redirects, and cache selection.

The edge is useful when the response varies by request but can still be computed with low latency and limited dependencies. It is a poor fit for heavy rendering that needs a private VPC database, large native modules, or long CPU bursts.

Web Components interoperability

Mon, 02 Mar 2026 09:00:00 -0400

Web Components are most valuable at boundaries: design systems used across frameworks, embeddable widgets, long-lived platform components, and islands inside applications that change framework stacks over time. Interoperability is the main promise, but it is not automatic. You get it by designing the component API around browser primitives that every framework can understand.


flowchart TD
 Host[React/Vue/Angular/Svelte app] -->|attributes/properties| Element[Custom element]
 Element --> Shadow[Shadow DOM internals]
 Element -->|CustomEvent| Host
 Host -->|slots| Element
 Element --> CSS[CSS custom properties/parts]

API mental model

A custom element has four public channels: attributes, properties, events, and slots. Attributes are string-based and declarative. Properties can hold richer values but require imperative assignment. Events are the portable callback mechanism. Slots let host markup provide content without the component knowing the host framework.

Prometheus Metric Cardinality Explosion

Sat, 28 Feb 2026 10:42:00 -0400

What cardinality actually means

In Prometheus, a single metric name is not one thing. Every unique combination of label values produces a distinct time series, and each series is stored, indexed, and queried independently. The cardinality of a metric is the number of distinct label-value combinations it produces. A cardinality explosion happens when that number grows far beyond what the operator anticipated, usually because a label was attached to a value that has high or unbounded variety.

Memory-Mapped Files vs Traditional I/O

Fri, 27 Feb 2026 09:14:00 -0400

When a service needs to read or write large files, the choice between traditional stream-based I/O and memory-mapped files (mmap) can change throughput, latency, and memory behavior by an order of magnitude. Both eventually move bytes between disk and process, but they take fundamentally different paths through the operating system. Understanding those paths is the difference between a database that sustains millions of reads per second and one that thrashes under load.

Actor Model vs Shared-Memory Concurrency

Thu, 26 Feb 2026 14:08:00 -0400

Concurrency is hard because two independent activities can touch the same data at the same time and corrupt it. Two broad philosophies have emerged to tame this. Shared-memory concurrency lets threads access common data and uses locks to coordinate. The actor model forbids shared mutable state entirely, replacing it with message passing between isolated entities. Understanding the trade-offs between these approaches shapes how you design everything from a single-process service to a globally distributed system.

Priority inversion in async code

Wed, 25 Feb 2026 15:10:00 -0500

Priority inversion happens when high-priority work waits behind low-priority work. In frontend code, it shows up when a click waits behind analytics, a keystroke waits behind JSON parsing, a route transition waits behind image processing, or an urgent state update is blocked by a long microtask chain. The main thread is a shared CPU, and JavaScript’s cooperative model means priority is only real if your code yields.

The mental model: async does not automatically mean non-blocking. A promise callback still runs on the main thread. await splits work into continuations, but each continuation can monopolize the event loop. Browser rendering, input handling, timers, network callbacks, and your framework scheduler all compete for turns.

Observability: OpenTelemetry Tracing Propagation

Tue, 24 Feb 2026 13:50:00 -0400

Mental model

In a monolith, a stack trace tells you the whole story of a request. In a distributed system, one user action might touch a gateway, three services, a queue, and two databases — across different processes, machines, and languages. A stack trace in any one of them shows only a fragment. Distributed tracing reassembles the fragments into a single coherent picture of the request’s journey.

The unit of that picture is the trace: a tree of spans, where each span represents one operation (an HTTP handler, a DB query, a queue publish) with a start time, duration, attributes, and a link to its parent. The magic that lets spans created in five different processes belong to one tree is context propagation — passing the trace identity across every process boundary the request crosses.

Event loop (macro vs microtasks)

Tue, 24 Feb 2026 09:30:00 -0500

The distinction between macrotasks and microtasks explains many frontend timing bugs. A task, often called a macrotask, is work such as a timer callback, input event, network callback, or script execution. A microtask is work scheduled to run immediately after the current JavaScript stack finishes and before the browser moves on to rendering or the next task. Promise callbacks, queueMicrotask, and mutation observer callbacks use this queue.


flowchart TD
 A[Pick next task] --> B[Run JS stack]
 B --> C[Drain all microtasks]
 C --> D{Microtasks added?}
 D -->|yes| C
 D -->|no| E[Render opportunity]
 E --> A

Mental model

Tasks are turns. Microtasks are cleanup at the end of the current turn. The browser drains the microtask queue completely before it considers painting or handling another task. That makes microtasks useful for preserving invariants: finish a state flush, notify subscribers, or resolve promise continuations before external events observe a half-updated state.

CORS preflight

Mon, 23 Feb 2026 12:25:00 -0500

Mental model

CORS preflight is the browser asking a server for permission before sending a cross-origin request that could have side effects or expose non-simple behavior. The browser sends an OPTIONS request with the intended method and headers. If the server responds with matching Access-Control-Allow-* headers, the real request proceeds.

Preflight is not authentication and not a firewall. It is a browser-enforced read/write permission protocol. Non-browser clients can ignore it, and same-origin requests do not need it.

Circuit Breaker and Bulkhead Patterns

Sun, 22 Feb 2026 10:15:00 -0400

Mental model

In a distributed system, the dangerous failures are not the ones that crash a single service — they are the ones that cascade. Service A calls service B. B gets slow. A’s threads pile up waiting on B. A runs out of threads and can no longer serve any request, including ones that have nothing to do with B. Now A is down, and everything that calls A starts to fail too. A slow dependency three hops away has taken down your whole platform.

Rate Limiting Algorithms: Token Bucket vs Leaky Bucket

Fri, 20 Feb 2026 16:25:00 -0400

Mental model

Rate limiting answers a deceptively simple question: should this request be allowed right now? The hard part is the “right now.” A naive counter — “max 100 requests per minute” — is full of edge cases around how time is divided and whether bursts are allowed. The mature algorithms exist precisely to handle those edges cleanly.

Two algorithms dominate the conversation, and they are often confused because both use a “bucket” metaphor. They are not the same:

Web Workers vs Service Workers

Fri, 20 Feb 2026 09:00:00 -0400

Web Workers and Service Workers both run off the main thread, but they solve different problems. A Web Worker is a compute companion for a page. A Service Worker is a network proxy and lifecycle-managed background agent for an origin. Confusing them leads to brittle caching, misplaced business logic, and debugging sessions where the code you changed is not the code currently controlling the page.


flowchart LR
 Page[Browser page] -->|postMessage| WW[Web Worker]
 WW -->|result| Page
 Page -->|fetch/navigation| SW[Service Worker]
 SW --> Cache[Cache Storage]
 SW --> Network[Network]
 SW --> Page

Mental model

A Web Worker is created by a page with new Worker(). It lives as long as the page keeps it alive. It is good for parsing large files, running search indexes, image processing, compression, WebAssembly, and any task that would otherwise create main-thread long tasks. It cannot intercept network requests for other pages and does not survive independently as a general daemon.

Concurrent rendering

Thu, 19 Feb 2026 11:30:00 -0500

Mental model: multiple possible futures

Concurrent rendering lets React prepare a future UI without immediately committing it. The current screen remains visible while React works on another version of the tree. If a more important update arrives, React can pause or abandon the older work and prepare a better future.

This is a rendering model, not a data-race model with multiple JavaScript threads. Your component code still runs on the main thread. The concurrency is about scheduling, interruption, prioritization, and choosing which completed tree becomes visible.

ResizeObserver loop limits

Thu, 19 Feb 2026 11:20:00 -0500

ResizeObserver closes a feedback loop

ResizeObserver reports element size changes. That sounds simple until the callback changes styles that change sizes again. The browser therefore runs ResizeObserver delivery in a guarded loop with a limit. When your callback keeps causing new resize notifications, the browser stops and reports a loop limit warning.


flowchart TD
 Layout["style and layout"] --> Gather["gather active resize observations"]
 Gather --> Callback["run ResizeObserver callbacks"]
 Callback --> Writes["callback writes size-affecting styles"]
 Writes --> Layout
 Callback --> Paint["paint when stable"]
 Gather --> Limit["loop limit exceeded"] --> Paint

The warning is not random. It means the browser protected rendering from an unstable measurement-write cycle.

OAuth2 Token Introspection vs JWT Validation

Wed, 18 Feb 2026 11:40:00 -0400

Mental model

When a resource server receives an OAuth2 access token, it must answer one question before doing anything else: is this token valid, and what does it authorize? There are two fundamentally different ways to answer it.

The first is local JWT validation: the token is a self-contained, signed JSON Web Token. The resource server verifies the signature with the authorization server’s public key and reads the claims directly. No network call.

Micro-frontend orchestration

Tue, 17 Feb 2026 13:20:00 -0500

Mental model: composition is the product

Micro-frontends are not primarily about splitting code. They are about splitting ownership while still shipping one coherent product. Orchestration is the layer that decides which independently built UI units load, where they mount, how they communicate, and what happens when one of them fails.

Without orchestration, a micro-frontend system becomes a set of teams deploying JavaScript into the same page and hoping version boundaries hold. A good shell gives teams autonomy while preserving routing, identity, observability, design constraints, and failure isolation.

SameSite cookie modes

Mon, 16 Feb 2026 08:40:00 -0500

Mental model

SameSite controls when the browser sends a cookie on cross-site requests. It is not about same-origin; it is about same-site, which is based on the registrable domain plus scheme. app.example.com and api.example.com are same-site, while example.com and example.net are cross-site.

The setting answers a narrow question: “Should this cookie be attached when the request was initiated from another site?” That makes it a major CSRF mitigation and a frequent source of auth bugs in embeds, OAuth, payment redirects, and local development.

GraphQL Resolver Batching and the N+1 Problem

Sun, 15 Feb 2026 14:05:00 -0400

Mental model

GraphQL’s execution model is a tree walk. The server resolves the root fields, then for each returned object it resolves that object’s selected fields, recursively. Each field has a resolver — a function that produces the value for that field given its parent object. This per-field resolution is what makes GraphQL flexible, and it is also exactly what creates the N+1 problem.

Consider a query for a list of posts and each post’s author:

Deterministic rendering

Sat, 14 Feb 2026 13:00:00 -0500

Deterministic rendering means the same inputs produce the same UI output, independent of timing, machine, locale, random numbers, request order, and hydration path. It is a prerequisite for reliable server rendering, visual regression tests, replayable bugs, and confident refactoring. Modern frontend stacks make nondeterminism easy because rendering is interleaved with async data, browser APIs, concurrent scheduling, and client-only effects.

The mental model: render should be a pure projection of explicit state. Anything that reads time, randomness, layout, global mutable data, storage, network state, or environment should be isolated before or after render and converted into stable inputs.

Browser memory leak detection

Sat, 14 Feb 2026 11:10:00 -0500

Browser memory leak detection is less about finding one magic number and more about proving that memory grows after repeated workflows when it should return to a stable baseline. JavaScript garbage collection is nondeterministic, browser processes share memory across systems, and DevTools changes runtime behavior. A good leak investigation controls the workflow, repeats it, forces diagnostic collections only when appropriate, and follows retaining paths to the owner.

The core distinction is retained memory versus allocated memory. Allocated memory is what your code creates over time. Retained memory is what remains reachable after the workflow finishes and garbage collection has had a chance to run. Leaks are retained memory problems. Jank from allocation churn may have stable retained memory but frequent GC.

gRPC Streaming and Flow Control

Fri, 13 Feb 2026 09:20:00 -0400

Mental model

gRPC is RPC semantics layered on top of HTTP/2. Every gRPC call is an HTTP/2 stream, and every message you send is a length-prefixed frame written into that stream. Once you internalize that mapping, streaming and flow control stop being magic: they are just HTTP/2 features that gRPC exposes through a friendlier API.

gRPC offers four call shapes. Unary is the classic request/response. Server streaming keeps the request single but lets the server push many messages. Client streaming reverses that. Bidirectional streaming opens both directions independently, which is the most powerful and the easiest to misuse.

Task starvation

Thu, 12 Feb 2026 11:00:00 -0500

Task starvation is what happens when important browser work cannot get a turn on the main thread. The page may not be frozen in the crash sense: JavaScript is running, promises are resolving, and state is changing. But input, rendering, timers, or lower-priority work are delayed because one source keeps scheduling more work ahead of them.


flowchart TD
 A[Task starts] --> B[Run JS]
 B --> C[Drain microtasks]
 C --> D{More microtasks queued?}
 D -->|yes| C
 D -->|no| E[Browser may render]
 E --> F[Next task]

Mental model

The event loop processes a task, drains the microtask queue, gives the browser a chance to render, then moves to the next task. Starvation appears when one phase keeps refilling itself. A long synchronous loop starves everything until it exits. An unbounded promise chain can starve rendering because microtasks must drain before the browser advances. A flood of high-priority app work can starve user-visible updates even if each unit is individually short.

CSRF vs XSS mitigation

Mon, 09 Feb 2026 13:10:00 -0500

Mental model

CSRF and XSS are both browser security problems, but they abuse different trust relationships. Cross-Site Request Forgery makes the browser send an authenticated request the user did not intend. Cross-Site Scripting runs attacker-controlled script inside the trusted origin.

CSRF asks, “Can another site cause this user’s browser to perform an action?” XSS asks, “Can attacker code run as this site?” XSS is usually more powerful because it can read page state, call same-origin APIs, and often bypass CSRF tokens by reading them.

Kafka Partition Rebalancing & Exactly-Once Semantics

Mon, 09 Feb 2026 09:35:00 -0400

Two of the most misunderstood parts of running Apache Kafka in production are how consumer group rebalancing works and what “exactly-once” actually guarantees. Both are areas where the defaults are reasonable but the failure modes are subtle, and where a confident-sounding wrong mental model leads to duplicate processing, stalled consumers, and data loss. This post digs into the mechanics of rebalancing, why it can cripple throughput, and how Kafka’s transactional machinery delivers exactly-once semantics — within the bounds of what is actually possible.

SharedArrayBuffer

Mon, 09 Feb 2026 09:00:00 -0400

SharedArrayBuffer gives multiple JavaScript agents access to the same memory. Unlike transferable ArrayBuffer, ownership does not move. The main thread and Workers can observe and modify shared bytes concurrently. That makes it powerful for low-latency coordination and dangerous when treated like ordinary JavaScript state.

The mental model is shared memory plus explicit synchronization. Reads and writes through typed arrays are not a message protocol. If one thread writes data and another reads it, you need a way to define when the data is ready. In browser JavaScript, that synchronization is the Atomics API over integer typed arrays.

CRDTs & Conflict-Free Replicated Data Types

Sat, 07 Feb 2026 11:25:00 -0400

When two replicas of the same data accept writes independently and then sync, something has to decide what the merged result is. The usual answer is “ask a server” or “last write wins,” and both have well-known failure modes: the server is a single point of contention, and last-write-wins silently throws away data. Conflict-free Replicated Data Types (CRDTs) take a different route. They are data structures designed so that any set of concurrent updates can be merged deterministically, without coordination, with the merge function guaranteeing that all replicas converge to the same state. No central authority, no conflict prompts, no lost updates — as long as the structure is built correctly.

MutationObserver cost

Fri, 06 Feb 2026 14:00:00 -0500

MutationObserver is a batch feed, not a free hook

MutationObserver reports DOM changes after they happen. It replaced synchronous mutation events because firing callbacks during every DOM write made layout engines slow and re-entrant. The modern API batches mutation records and delivers them at a microtask checkpoint. That batching is useful, but it can hide large costs until a busy render path suddenly spends milliseconds processing records.


sequenceDiagram
 participant JS as JavaScript task
 participant DOM as DOM mutations
 participant Q as Mutation record queue
 participant MO as Observer callback
 JS->>DOM: append/remove/setAttribute
 DOM->>Q: enqueue records
 JS->>JS: finish current call stack
 Q->>MO: deliver at microtask checkpoint
 MO->>DOM: optional follow-up reads/writes

The important mental model is “you pay for what you observe.” Broad observation turns DOM churn into record allocation, queueing, callback work, and often secondary DOM queries.

Time slicing

Thu, 05 Feb 2026 13:40:00 -0500

Time slicing is the renderer’s ability to split render work into smaller chunks so the browser can handle input, paint, and higher-priority tasks between chunks. It does not make JavaScript run in parallel. It makes long rendering work cooperative instead of monopolizing the main thread.

The main thread has many customers: event handlers, style recalculation, layout, painting, timers, network callbacks, and framework rendering. A render that takes 80 milliseconds blocks all of them. Time slicing aims to turn that into several smaller units so a click, keypress, or animation frame can be serviced before the user perceives the page as frozen.

RabbitMQ Dead-Letter Queues & Message Ordering

Thu, 05 Feb 2026 13:05:00 -0400

RabbitMQ gives you two capabilities that look simple on the surface and turn out to have a lot of depth: dead-letter queues for handling messages that cannot be processed, and message ordering for workloads that depend on sequence. Most teams configure the first one slightly wrong and assume the second is stronger than it is. This post covers how dead-lettering actually works, the retry-loop trap it creates, and the precise conditions under which RabbitMQ does and does not preserve order.

Detached DOM nodes

Thu, 05 Feb 2026 08:35:00 -0500

A detached DOM node is a node that is no longer connected to the document tree but is still retained by JavaScript or browser internals. Detached nodes are not automatically leaks. A framework may temporarily hold nodes during reconciliation, an animation library may stage elements before disposal, and a virtual scroller may reuse nodes. They become a leak when the application no longer needs them but something keeps them reachable.

CAP Theorem in Practice

Tue, 03 Feb 2026 14:40:00 -0400

Almost everyone who works with distributed databases has heard the CAP theorem reduced to a slogan: “pick two of consistency, availability, and partition tolerance.” That summary is so lossy it is actively harmful. It implies you sit down at design time and choose two letters off a menu. In reality, partition tolerance is not optional, the choice between consistency and availability only matters during a partition, and the words “consistency” and “availability” in CAP mean something narrower and stranger than their everyday usage. This post unpacks what the theorem really says and how it shows up in systems you actually run.

Finite state modeling

Tue, 03 Feb 2026 11:45:00 -0500

Mental model: make impossible states unrepresentable

Finite-state modeling is the practice of describing UI behavior as a set of named states and allowed transitions. The point is not academic purity. The point is to stop representing contradictory UI conditions with independent booleans such as isLoading, hasError, isDirty, isSaving, and isSuccess.

If a form can be both isSaving: true and hasError: true, every render branch must guess what that means. A state machine makes the mode explicit: editing, submitting, submitFailed, or submitted.

Idempotent UI actions

Tue, 03 Feb 2026 09:45:00 -0500

An idempotent UI action can be invoked more than once and still leave the application in the same intended state. Users double-click, mobile browsers retry taps after jank, network clients retry requests, tabs restore after crashes, and optimistic interfaces replay local mutations. If the UI action is not idempotent, those ordinary behaviors become duplicate orders, double votes, repeated messages, or corrupted client state.

The frontend mental model should mirror distributed systems: every meaningful mutation has an identity, a target state, and a reconciliation path. “Add one more” is fragile. “Set this item to selected for action id X” is much easier to retry safely.

Layout thrashing

Tue, 03 Feb 2026 08:45:00 -0500

Layout thrashing happens when JavaScript repeatedly alternates between writing DOM or style changes and reading layout-dependent values. Each read asks the browser for up-to-date geometry. If there are pending writes, the browser must synchronously recalculate style and layout before returning the value. In a loop, that creates many forced layouts where one batched layout would have been enough.


flowchart TD
 A[Write style] --> B[Layout marked dirty]
 B --> C[Read offsetWidth]
 C --> D[Forced style and layout]
 D --> E[Write style again]
 E --> B

Mental model

Browsers normally batch rendering work. JavaScript mutates the DOM, then the browser waits until the task ends and prepares the next frame. Layout thrashing defeats that batching by demanding geometry in the middle of mutation work.

Content Security Policy (CSP)

Mon, 02 Feb 2026 09:00:00 -0500

Mental model

Content Security Policy is a browser-enforced allowlist for what a page may load, execute, embed, connect to, and submit to. Its highest-value use is XSS damage reduction: even if an attacker injects markup, CSP can block inline script, remote script, plugin loads, and data exfiltration paths.

CSP is not a sanitizer. It is a runtime constraint. Good CSP assumes bugs will happen and makes successful exploitation harder.


graph TD
 A["HTML response"] --> B["CSP header"]
 B --> C["Browser policy engine"]
 C --> D["script-src"]
 C --> E["connect-src"]
 C --> F["img/style/frame directives"]
 D --> G["Allow nonce/hash scripts"]
 D --> H["Block inline or unknown script"]

Internals that matter

A policy is delivered by HTTP header or a meta tag. Prefer headers because they apply earlier and support reporting. Directives fall back to default-src when absent, but not all directives behave identically. A practical baseline separates script, style, images, fonts, frames, workers, and network connections.

Eventual Consistency Anti-Patterns

Sun, 01 Feb 2026 16:50:00 -0400

Eventual consistency is a deal: you give up the guarantee that a read immediately reflects the latest write, and in exchange you get availability, lower latency, and horizontal scale. It is a perfectly good deal for the right workloads. The trouble starts when teams adopt an eventually consistent store — DynamoDB, Cassandra, an event-driven microservice mesh, a read replica — and then write code as if it were strongly consistent. The bugs that follow are intermittent, environment-dependent, and nearly impossible to reproduce on a developer laptop. This post catalogs the recurring anti-patterns and the patterns that actually work.

Distributed Locking: Redlock Pitfalls

Fri, 30 Jan 2026 10:15:00 -0400

Distributed locks are one of those primitives that look trivial until you deploy them. A single-node mutex protects a critical section because the operating system guarantees that only one thread holds it at a time. The moment you spread that critical section across machines, the guarantees you took for granted evaporate. Clocks drift, processes pause, networks partition, and the lock you thought you held has quietly expired and been granted to someone else.

Transferable objects

Thu, 29 Jan 2026 09:00:00 -0400

Transferable objects are the difference between “send this data to a Worker” and “move ownership of this memory to a Worker.” That distinction is critical for large binary payloads. Structured cloning copies data. Transferring detaches the object from the sender and makes the receiver the owner, avoiding a large copy on the hot path.

The mental model is move semantics for browser concurrency. After transfer, the sender’s buffer is intentionally unusable. That can feel surprising in JavaScript because most values are shared by reference or copied by value, but it is exactly what makes transfer cheap.

Garbage collection timing

Tue, 27 Jan 2026 13:20:00 -0500

Garbage collection timing is one of the least deterministic parts of frontend performance. JavaScript gives you automatic memory management, but it does not promise when memory will be reclaimed. That uncertainty matters because collection work can happen during interactions, route transitions, animation, or hydration, and the resulting pauses can look like random jank.

The practical mental model is reachability. Objects are collectible only when the engine can prove they are no longer reachable from roots: global variables, active stack frames, closures, pending timers, DOM references, event listeners, and internal engine structures. Timing is separate from eligibility. An object can be garbage and still remain in memory until a later collection cycle.

Trusted Types

Mon, 26 Jan 2026 14:20:00 -0500

Mental model

Trusted Types is a browser enforcement layer that moves DOM XSS prevention from “remember to sanitize every string” to “dangerous DOM sinks reject plain strings.” It does not sanitize by itself. It forces code to pass values created by approved policies, such as TrustedHTML, TrustedScript, or TrustedScriptURL.

The goal is to reduce the number of places where XSS can enter. Instead of auditing every innerHTML assignment, you audit the small set of policies that are allowed to create trusted values.

Two-Phase Commit vs Saga Pattern

Mon, 26 Jan 2026 10:33:00 -0400

The problem of distributed atomicity

A single database gives you atomic transactions for free: a transfer that debits one account and credits another either fully commits or fully rolls back. The moment that logic spans multiple services or databases — order service, payment service, inventory service — that guarantee vanishes. There is no COMMIT that spans three databases owned by three teams. You now need a protocol to make several independent commits behave as one logical unit, or to clean up convincingly when they cannot.

Deadlock Detection and Prevention

Sat, 24 Jan 2026 16:48:00 -0400

The shape of a deadlock

A deadlock is the concurrency equivalent of two people in a hallway, each stepping the same direction to let the other pass, forever. Formally, it is a cycle of processes each holding a resource the next one needs. No process can proceed, none will release what it holds, and without intervention they wait indefinitely.

Deadlocks appear anywhere there is shared, exclusive resource acquisition: database row locks, mutexes in application code, distributed locks across services, file locks. The mechanisms differ, but the theory is universal, and it is worth understanding deeply because deadlock bugs are intermittent, load-dependent, and notoriously hard to reproduce.

Accessibility tree

Sat, 24 Jan 2026 11:20:00 -0500

The accessibility tree is the browser’s semantic projection of the page. It is derived from the DOM, CSS, native element semantics, ARIA, and computed state, then exposed through platform accessibility APIs. Screen readers, switch devices, voice control, automated accessibility tooling, and browser devtools all depend on this projection.

The important mental model is that users of assistive technology do not consume your DOM directly. They consume roles, names, descriptions, states, relationships, and actions. A visually polished custom control can be invisible or misleading if its accessibility tree node is wrong.

Reconciliation algorithm

Thu, 22 Jan 2026 10:15:00 -0500

Mental model: preserve identity where the shape matches

Reconciliation is the process of turning a previous UI tree and a next UI tree into the minimal set of renderer operations React cares to compute. It is not a general tree-edit-distance algorithm. React uses practical heuristics: different component types produce different subtrees, and children with stable keys represent stable identity across renders.

The goal is not theoretical minimum DOM edits; the goal is predictable component identity and fast enough diffing. When type and key match, React can reuse the existing fiber and preserve state. When either changes, React treats the old node as replaced and mounts a new one.

Query Planner and Cost-Based Optimization

Thu, 22 Jan 2026 11:05:00 -0400

From declarative to executable

SQL is declarative: you state what you want, not how to get it. Between your query and the disk sits one of the most sophisticated pieces of software in a database — the query optimizer — whose job is to transform a logical request into an efficient physical execution plan. For any non-trivial query there are thousands of equivalent plans that differ in cost by orders of magnitude. Choosing well is the difference between a 5ms response and a 5-minute table scan.

IndexedDB

Thu, 22 Jan 2026 09:30:00 -0500

IndexedDB is a transactional object store

IndexedDB is the browser’s built-in durable database for structured client data. It is not localStorage with promises. It is closer to a small transactional database with object stores, indexes, versioned schema upgrades, structured cloning, and browser-managed quota. The API looks unusual because it predates promises and because transactions are tied to the event loop.


graph TD
 App["application code"] --> DB["IDBDatabase connection"]
 DB --> Tx["transaction: readonly/readwrite"]
 Tx --> Store["object store"]
 Store --> Record["structured cloned records"]
 Store --> Index["secondary indexes"]
 Index --> Cursor["range scans and cursors"]

The core mental model: open a database at a numeric version, create stores and indexes only during upgrade, then do all reads and writes inside transactions. Transactions auto-commit when their request queue drains and the current task finishes.

Critical rendering path

Wed, 21 Jan 2026 10:20:00 -0500

The critical rendering path is the sequence of browser work required to turn bytes into pixels. It starts with the network response and ends with a frame on screen. The useful part of the model is that each stage can block or invalidate later stages: HTML creates the DOM, CSS creates the CSSOM, both combine into a render tree, layout computes geometry, paint records drawing commands, and compositing places layers on screen.

B-tree vs LSM-tree Index Internals

Mon, 19 Jan 2026 15:18:00 -0400

Two answers to the same question

Every storage engine has to answer one question: given a key, how do I find its value on disk quickly, and how do I keep that structure efficient as data changes? For decades the answer was the B-tree, the structure beneath PostgreSQL, MySQL’s InnoDB, and nearly every relational database. Then the write-heavy era — logging, time series, event streams — made a different answer attractive: the Log-Structured Merge-tree (LSM-tree), which powers RocksDB, Cassandra, LevelDB, and ScyllaDB.

DOM clobbering

Mon, 19 Jan 2026 11:15:00 -0500

Mental model

DOM clobbering is a browser legacy behavior where elements with certain id or name attributes become properties on global objects like window, document, or forms. If application code expects window.config to be a trusted object, injected markup like <form id="config"> may replace that lookup with an element.

This is not the same as executing script. It is a confused-reference bug: attacker-controlled markup changes what a variable resolves to. The impact depends on how that reference is used. If clobbered data becomes a URL, sanitizer option, feature flag, or script source, it can become a real security vulnerability.

Event sourcing in frontend

Mon, 19 Jan 2026 09:30:00 -0500

Mental model: state is a projection

Event sourcing on the frontend means the primary record of change is an append-only event stream, and the UI state is a projection derived from that stream. Instead of storing only currentCart, you store facts such as ItemAdded, QuantityChanged, and CouponRemoved, then fold them into the current view model.

This is not the right default for every app. It earns its complexity when you need undo/redo, auditability, collaborative reconciliation, offline replay, or deterministic debugging. If the app is mostly forms submitted once, a normal normalized store is easier.

OffscreenCanvas

Sun, 18 Jan 2026 09:00:00 -0400

OffscreenCanvas moves canvas rendering away from the main thread. That matters when canvas work competes with input handling, layout, style recalculation, framework updates, and accessibility tree changes. The goal is not automatically higher frame rates; the goal is isolating expensive drawing so the main thread can stay responsive. A canvas can still be slow in a Worker, but its slowness no longer blocks a text input or a route transition as directly.

ACID vs BASE Trade-offs

Sat, 17 Jan 2026 13:27:00 -0400

Two philosophies of data

When a system stores data that multiple clients read and write, it must make promises about what they will see. ACID and BASE are two opposing sets of promises. ACID — Atomicity, Consistency, Isolation, Durability — is the relational tradition: the database guarantees correctness even under concurrency and failure, and the application can largely ignore the messy middle. BASE — Basically Available, Soft state, Eventually consistent — emerged from web-scale systems that found ACID’s guarantees too expensive at planetary scale and chose to relax them in exchange for availability and horizontal scalability.

PerformanceObserver API

Fri, 16 Jan 2026 10:40:00 -0500

PerformanceObserver is the browser’s streaming interface for performance timeline entries. Instead of polling performance.getEntriesByType(), you subscribe to entry types and receive batches as the browser records them. That makes it the foundation for production measurement of navigation timing, resource timing, paint timing, layout shifts, long tasks, event timing, and custom marks.

The key mental model is that the browser maintains performance timelines. Different subsystems append entries to those timelines. PerformanceObserver lets your code consume those entries asynchronously without blocking the subsystem that produced them.

ARIA live regions internals

Fri, 16 Jan 2026 10:30:00 -0500

ARIA live regions are a bridge between DOM mutation and assistive technology announcement queues. They look deceptively small: add aria-live="polite" and update text. In real interfaces, they are a timing-sensitive contract across your framework renderer, the browser accessibility tree, platform accessibility APIs, and the screen reader’s own queueing rules.

The mental model: a live region is not “read this element.” It is “when this already-known region changes, expose an announcement-worthy delta.” That means the region should exist before the update, the mutation should be meaningful, and repeated updates need throttling.

Database Transaction Isolation Levels: Serializable vs Snapshot

Fri, 16 Jan 2026 09:42:00 -0400

Why isolation levels exist

A database that ran every transaction one at a time would be trivially correct and uselessly slow. Real systems interleave transactions to keep CPUs and disks busy, and that interleaving is where correctness goes to die. Isolation levels are the contract the database offers about which concurrency anomalies you are allowed to observe. Pick a weaker level and you trade some correctness guarantees for throughput; pick a stronger one and you pay in aborts, latency, or lock contention.

Render blocking resources

Wed, 14 Jan 2026 09:10:00 -0500

Render-blocking resources are files the browser must fetch, parse, or execute before it can safely paint useful pixels. The common examples are stylesheets in the document head and synchronous scripts that appear before content. The deeper model is dependency management: the browser is trying to avoid painting a page with incorrect style or running script against a document state that later changes underneath it.

The cost is not only network time. A stylesheet blocks first paint while it is discovered, downloaded, parsed, and matched against the DOM. A classic script blocks HTML parsing while it downloads and executes, and if that script reads computed style it may also force style and layout work that depends on earlier CSS.

Zero-Downtime Deployment Strategies

Tue, 13 Jan 2026 13:05:00 -0400

What “zero downtime” actually requires

Zero-downtime deployment means rolling out a new version of a service without any request failing because of the deployment itself. That is a stricter requirement than it sounds. It is not enough to start the new version before stopping the old one. You also have to handle in-flight requests on the instances you are about to kill, keep the load balancer’s view of healthy instances accurate, and ensure the database schema is compatible with both the old and new code at every instant during the rollout.

Prototype pollution

Mon, 12 Jan 2026 10:45:00 -0500

Mental model

Prototype pollution is a JavaScript object graph bug where attacker-controlled input writes properties onto Object.prototype or another shared prototype. Once polluted, ordinary objects appear to have attacker-chosen defaults. The dangerous part is not the write itself; it is later code that trusts property lookup.

The classic payload is a nested key like __proto__.isAdmin=true, constructor.prototype.debug=true, or JSON shaped to trick a merge function. If a parser or deep merge helper treats those keys as normal object paths, it mutates the prototype chain instead of only the target object.

HTTP/3 and QUIC Packet Loss Recovery

Sun, 11 Jan 2026 16:50:00 -0400

Why QUIC reinvented loss recovery

HTTP/3 runs over QUIC, and QUIC runs over UDP. UDP gives you nothing: no ordering, no retransmission, no congestion control, no connection concept. QUIC rebuilds all of it in user space, on top of UDP, and in doing so it gets to fix the parts of TCP that were impossible to change because TCP is baked into operating system kernels and middleboxes.

The most important thing QUIC fixes is the interaction between loss recovery and stream multiplexing. HTTP/2 multiplexes streams over a single TCP connection, but TCP delivers a single, ordered byte stream. If one TCP segment is lost, the kernel holds back every later byte, across all HTTP/2 streams, until the missing segment is retransmitted. That is transport-layer head-of-line blocking, and HTTP/2 cannot escape it because it does not control TCP. QUIC controls its own transport, so it can make loss on one stream affect only that stream.

Service Worker lifecycle traps

Fri, 09 Jan 2026 10:15:00 -0500

The lifecycle is a deployment protocol

A service worker is not just a background script. It is a versioned proxy that the browser installs, validates, pauses, restarts, and swaps independently from page JavaScript. Most production bugs come from treating it like an immediately loaded bundle. The browser treats it more like an update transaction: a candidate worker installs, waits until old controlled clients go away, then activates and begins handling fetches.

TLS 1.3 Handshake Internals

Thu, 08 Jan 2026 14:40:00 -0400

What TLS 1.3 changed and why it matters

TLS 1.3 (RFC 8446) is not an incremental tweak of TLS 1.2. It is a redesign that removed a decade of accumulated insecurity and shaved a full round trip off connection setup. The two headline numbers: a full handshake costs one round trip (1-RTT) instead of two, and resumed connections can send application data immediately (0-RTT). To understand how it achieves this, you need to follow the messages and the key derivation in lockstep.

Optimistic UI rollback strategy

Thu, 08 Jan 2026 10:15:00 -0500

Mental model: speculative state with an audit trail

Optimistic UI is not “update the screen before the server responds.” That is only the visible part. The useful mental model is speculative execution: the client applies a predicted mutation, records enough context to undo or reconcile it, and later commits, patches, or rolls it back when the authoritative response arrives.

The mistake is treating optimistic state as a boolean flag. A real rollback strategy needs an operation log. Each optimistic operation should have an id, target entity, before snapshot or inverse patch, predicted after state, request status, and conflict policy. Without that metadata, failures turn into hand-written edge cases scattered across components.

Race conditions in UI state

Thu, 08 Jan 2026 09:30:00 -0500

Mental model

A UI race condition happens when two or more state transitions are valid in isolation but arrive in an order the user, product, or component did not intend. The browser is single-threaded for most JavaScript, but it is not single-causal. User input, network responses, timers, animation frames, workers, and framework schedulers all enqueue work. The bug is rarely “two lines ran at the same time”; it is “an old result committed after the UI had already moved on.”

Fiber architecture

Thu, 08 Jan 2026 09:20:00 -0500

Mental model: rendering as interruptible work

Fiber is React’s internal representation of a component tree and the unit of work used by the renderer. The old stack reconciler behaved like a recursive function call: once rendering started, it ran until the call stack unwound. Fiber turns that stack into a linked data structure that React can pause, resume, discard, and prioritize.

Think of a fiber node as a work record for one component or host element. It stores the component type, props, state, pending updates, child and sibling links, effects, lanes, and a pointer to the previous committed version. Rendering is not simply “call all components”; it is building a work-in-progress tree that can later be committed if it still represents the best answer.

Long tasks API

Thu, 08 Jan 2026 09:15:00 -0500

The Long Tasks API is a browser performance API for answering a narrow but important question: when was the main thread unavailable long enough for users to feel it? It does not tell you every function call, every layout, or every promise continuation. It reports tasks that block the main thread for more than 50 ms, which is the threshold browsers use to identify work that can delay input handling, rendering, timers, and other user-visible activity.

Pointer events

Thu, 08 Jan 2026 09:15:00 -0500

Pointer Events are the browser’s unification layer for mouse, touch, pen, and trackpad-like pointing input. They are not just “mouse events with a different name.” They expose a stream model that carries device identity, pressure, contact geometry, capture state, cancellation, and compatibility behavior. If you build draggable surfaces, drawing tools, sliders, resizers, maps, or gesture-heavy components, Pointer Events are usually the right primitive.

The mental model is simple: a pointer is a single active contact. A mouse usually has one persistent pointer. A touchscreen can have many simultaneous pointers. A stylus has one pointer with richer metadata. Your code should track pointer state by pointerId, not by global booleans such as isDragging.

WebAssembly integration

Thu, 08 Jan 2026 09:00:00 -0400

WebAssembly integration is not “rewrite the frontend in Rust.” In a browser application it is usually a narrow acceleration boundary: JavaScript keeps ownership of UI, routing, networking, storage, and orchestration, while a WebAssembly module owns a small deterministic core such as parsing, image processing, compression, cryptography, simulation, or rules evaluation.

The useful mental model is a foreign function interface inside the page. Calls cross from JavaScript into a linear memory owned by the module. That crossing has overhead. The module is fast once it is running, but strings, objects, callbacks, and DOM access still live on the JavaScript side. Good integrations therefore minimize crossings and move batches of primitive data through memory.

HTTP/2 Multiplexing and HPACK

Mon, 05 Jan 2026 11:25:00 -0400

The problem HTTP/2 set out to solve

HTTP/1.1 has a structural flaw: a single TCP connection can carry only one request-response exchange at a time. The connection processes requests strictly in order. If the first response is slow, everything behind it waits. This is head-of-line blocking at the application layer, and it is brutal for modern pages that pull dozens or hundreds of resources.

Browsers worked around it by opening six or more parallel connections per origin. That helps, but each connection has its own TCP slow start, its own congestion window, and its own setup cost, and the browser still runs out of connections long before it runs out of resources to fetch. Sharding assets across multiple domains to get more connections was a common, ugly hack.

TCP Congestion Control Algorithms

Sat, 03 Jan 2026 09:15:00 -0400

Why congestion control exists

A TCP sender has two limits on how fast it can transmit. The first is the receiver’s advertised window (rwnd), which protects the receiver’s buffer. The second is the congestion window (cwnd), which protects the network. Without the second limit, every sender would dump packets into shared links as fast as the receiver could absorb them, queues would overflow, routers would drop packets en masse, and the whole network would collapse into a state where almost everything retransmits and almost nothing makes progress. That scenario actually happened on the early internet in 1986, and congestion control is the response.

Connection Pooling Pitfalls

Fri, 02 Jan 2026 08:30:00 -0400

Why pools exist and why they bite

Opening a database connection is expensive. There is a TCP handshake, often a TLS handshake, authentication, and server-side allocation of a backend process or thread plus memory. For Postgres specifically, each connection is a full OS process. Establishing one can take tens of milliseconds, which is catastrophic if you do it per request.

A connection pool amortizes that cost. The application keeps a set of open connections, hands one to a request that needs it, and returns it to the pool when the request finishes. In the happy path this is invisible. The pitfalls show up under load, during failures, and in the gaps between what the pool thinks is true and what the database actually believes.

Job Search Nightmare

Wed, 19 Dec 2018 09:49:35 -0500

Rant Post

I have been looking for opportunities in technology/design sector for a while now. This post entails the pain and suffering which I have faced in last 5 months.

Recruiters only contact you when you are happy at your workplace and when you want to move on, it becomes like screaming in a void and there is no one to listen.

The usual sources for finding the opportunities are LinkedIn, Indeed, Glassdoor. Been browsing these websites for months now I have experienced they put in a lot of effort in just dumping the data without proper formatting or analysis. They both suffer from massive user experience issues, but that’s for another post. Let the rant begin.

Mule Transaction Management

Fri, 09 Nov 2018 14:05:20 -0500

Definition

Defines a context to execute all the steps in a mule flow. The scope enables none or all functionality. If any error occurs in any of the step, the whole flow is reverted.

Transactions management in mule has always been a topic of interest for many. It gives the flexibility of using a pre-defined rollback strategy if doing multiple database operations. Though the Transactional scope is only available when using Database Connector or JMS connector.

Three Layered Architecture

Thu, 05 Jul 2018 21:03:51 -0400

Whatever good things we build end up building us.

Taking inspiration from the quote above; API design decisions should be driven by what precisely the API will link and what will be on either side of the interface. The architecture explained in this post is being popularized by Mulesoft API design architecture.

Let’s explore this architecture and explain about what is the purpose of each layer and how are they interlinked.

API Design Guidelines

Fri, 01 Jun 2018 08:00:22 -0400

`All good things must come to an api endpoint`

Most of the real world application these days work by calling some sort of API to display or process data. API led connectivity has increased the pace of development. It is very similar to putting lego blocks together to build something useful.

With the evolution of API, there are 2 major principles which drives the success

Platform Agnostic: A client should be able to call the API, regardless of how the API is implemented internally. The complexity should be hidden and the contract between the API and the client should define the mechanism of data exchange.

Canonical Data Model

Wed, 30 May 2018 21:59:50 -0400

Definition

It’s the model is a design pattern which defines the communication protocol between various enterprise systems.

With software industry switching focus from monolithic apps to micro-services, there is always a need for the better communication model between each other. Most of the API based connectivity is architect for following proper REST principles and single responsibility. There is not much thought given for the communication model between the services.

Been in a team of 20 software engineers, I have experienced that every developer has a way to write the definition for the service.

About

Tue, 29 May 2018 07:53:53 -0400

Have been working in Software development industry for 7+ years. Experienced in FinTech and Retail PLM development.

Currently focussing on API led development and Service Oriented Architecture.

Contact

Mon, 21 May 2018 08:50:06 -0400

Have any question, suggestions or jokes ?!?
Please contact me at: vaibhavsomani@live.in