The JavaScript event loop beyond the usual diagram
Move beyond the stack-and-queue diagram by tracing what actually happens between a task, its microtasks, and the browser’s next rendering opportunity.
Loading articles…
Clear explanations for systems that are easy to build and hard to understand.
I write about the systems behind modern applications—from JavaScript and React in the browser to Node.js services, containers, AWS, and the infrastructure that holds everything together.
Latest articles
View allWebSockets or Server-Sent Events? Choose from failure modes
WebSockets and SSE are easy to compare by features. The better choice appears when you compare how each behaves during disconnects, deploys, and load spikes.
React performance: measure renders before memoizing
Before adding memoization, identify whether the real problem is repeated rendering, expensive rendering, a costly commit, or something outside React entirely.
How concurrent rendering changes the way React feels
Concurrent rendering is easier to reason about when you see it as interruptible preparation with an atomic commit—not as background threads for components.
Backpressure is the hidden contract in Node.js streams
Node.js streams are not memory-efficient by default; they become efficient when every stage respects backpressure instead of buffering without a limit.
Designing idempotent APIs in Node.js
A reliable Node.js API assumes clients and infrastructure will retry—and gives repeated requests the same observable result without repeating the side effect.
Production Docker images for Node.js without the bloat
Multi-stage builds help, but reliable Node.js containers also require deliberate dependency installation, signal handling, security, and build context control.
A practical path from Docker Compose to Amazon ECS
ECS becomes easier when you map the responsibilities hidden by local Docker Compose: networking, secrets, health checks, identity, logs, and safe deployments.
Event-driven AWS systems without the service maze
Choose AWS messaging services by the delivery and coupling problem you actually have, then design retries, idempotency, and observability as one system.
Caching is easy; invalidation is the system
Caching becomes a system-design problem the moment a second copy of data can outlive the request that created it. Start with acceptable staleness, not Redis.
