Insights on Manas Yadav

Graceful Shutdown in Kubernetes for Go and Node.js Services

Thu, 08 Oct 2026 00:00:00 +0000

Does your error rate tick up a little on every deploy? That’s probably not a bug in the new version. It’s a shutdown problem. A handful of 502s and connection resets per rollout is so common that lots of teams treat it as normal. It isn’t, and the fix is mostly plumbing.

What actually happens when a pod is terminated

When Kubernetes stops a pod (a rollout, a scale-down, a node drain), two things start at the same time:

Backpressure and Load Shedding: Keeping Services Alive Under Overload

Tue, 06 Oct 2026 00:00:00 +0000

Services rarely die from a bit more traffic than they can handle. They die because they accept that traffic, queue it up, and then serve every request slowly instead of serving most of them quickly. Latency climbs. Clients time out and retry, the queue grows faster, and before long the service is busy working on requests nobody is waiting for anymore.

The fix feels backwards: to stay up under overload, a service has to say no to some work, early and cheaply.

Timeouts, Retries, and Backoff: How to Call Other Services Without Causing an Outage

Sun, 04 Oct 2026 00:00:00 +0000

A network call can fail fast, fail slowly, or never come back. Failing fast is the easy case. The other two cause outages. A missing timeout ties up resources until the process runs out, and a naive retry takes a struggling dependency and hits it three times harder while it’s down.

Timeout and retry logic gets copy-pasted around every backend I’ve seen, and it’s dangerous to get wrong. Here’s how I think about it.

The Transactional Outbox Pattern and Idempotent Consumers, Explained

Thu, 01 Oct 2026 00:00:00 +0000

This looks completely reasonable. It’s quietly broken:

func PlaceOrder(ctx context.Context, o Order) error {
	if err := db.InsertOrder(ctx, o); err != nil {
		return err
	}
	return producer.Publish(ctx, "orders.placed", o)
}

If the process crashes, the network blips, or Kafka is briefly unavailable between those two lines, the order exists but the event never goes out. The warehouse never ships it. The email never sends. Swap the calls around and you get the opposite: an event for an order that was never saved.

That’s the dual-write problem. You want to update two systems atomically and no transaction spans both. Retries don’t help, because you can’t tell whether the first attempt partly succeeded.

Reading PostgreSQL EXPLAIN ANALYZE: A Backend Engineer's Guide to Slow Queries

Mon, 28 Sep 2026 00:00:00 +0000

Most slow API endpoints I’ve looked at weren’t slow because of application code. They were slow because of one query, and that query was slow because Postgres picked a plan nobody expected. EXPLAIN ANALYZE shows you that plan. Reading it well is one of the most useful skills a backend engineer can pick up.

Always use ANALYZE and BUFFERS

Plain EXPLAIN shows what Postgres plans to do. EXPLAIN ANALYZE runs the query and shows what actually happened. Add BUFFERS to see how much data it touched:

Kafka at Scale: Partitions, Consumer Lag, Rebalancing, and Running It in Production

Wed, 23 Sep 2026 00:00:00 +0000

Kafka will take almost anything you throw at it on day one. The trouble comes later. A topic can’t keep up because it has too few partitions. Consumers stop for 30 seconds every time a pod restarts. One broker runs hot while the rest idle. Nothing exotic, just the defaults meeting real traffic.

These are the decisions I think matter most once Kafka is load-bearing. For the “why” behind the storage and replication model, read Kafka internals first.

Kafka Internals: Logs, Segments, Replication, and the ISR Explained

Wed, 16 Sep 2026 00:00:00 +0000

Kafka is easy to use and hard to operate well. Nearly all of the gap is internals. Once you know how a partition sits on disk and how replicas agree on what’s committed, most of the config options stop looking like magic. They turn into fairly obvious trade-offs.

I’ll go bottom up: one partition on one disk, then replication, then producers and consumers. The operational side lives in the companion post on running Kafka at scale.

Go Performance Debugging: A Practical Guide to pprof, Traces, and the GC

Wed, 09 Sep 2026 00:00:00 +0000

Go makes it easy to write fast code. It also makes it easy to write code that’s slow for reasons you’ll never spot by reading it. The tooling to find out why ships with the language and is safe to run in production. Most teams barely touch it.

Here’s the workflow I follow when a Go service is slower than it should be, roughly in the order the steps tend to pay off.

Event Loop Lag in Node.js: Using It to Debug Performance and CPU Throttling

Wed, 02 Sep 2026 00:00:00 +0000

A slow Node.js service sends most people straight to request latency and downstream calls. Reasonable, but it misses the most common Node-specific failure, which is the event loop itself falling behind. When that happens every request in the process slows down at once, including the ones that do nothing expensive.

Event loop lag catches it. It’s cheap to collect and easy to read once you know the patterns. It’s also the best tool I know for spotting something dashboards usually hide: CPU throttling in containers.

Node.js Event Loop Internals: What Actually Runs When

Wed, 26 Aug 2026 00:00:00 +0000

“Node is single-threaded” is one of those statements that’s true enough to repeat and wrong enough to cause outages. Your JavaScript runs on one thread. Node itself doesn’t. Knowing where that line sits is the difference between a service that handles 10k concurrent connections calmly and one that falls over the first time someone uploads a big JSON file.

So here’s what the loop actually does, in order, followed by the mistakes that block it.

Distributed Locking Patterns in High-Concurrency Microservices

Tue, 18 Aug 2026 00:00:00 +0000

A sync.Mutex protects memory inside one process. The moment you run three replicas of a service on Kubernetes, each pod has its own mutex, and they know nothing about each other. If two pods pick up work for the same customer at the same time, the mutex does nothing to stop them.

That’s when people reach for a distributed lock. Fair enough, they’re useful. They’re also one of the easiest things in backend engineering to get subtly wrong, and quite often they’re not the right tool in the first place.

Building High-Throughput Kafka Event Pipelines in Go

Sun, 02 Aug 2026 00:00:00 +0000

Most Go Kafka services start out as a consumer loop, a channel, and a handful of goroutines reading from it. Fine at a few hundred messages a second. At tens of thousands, ordering breaks, memory climbs, and latency gets spiky in ways dashboards don’t explain.

Below is the shape I reach for when a pipeline has to be fast and correct.

The naive version and what goes wrong

Here’s the pattern almost everyone writes first: