Don’t Make Your Users Wait: Parallelism in Kubernetes Operators

Sun, 17 May 2026 05:03:52 +0000

Note: This is hand written blog and further refractored but not an AI Slop.

The Restaurant Example#

Now, here is the story. Let’s say you are in a restaurant which has only one counter to take the order and each order is taking 1 minute to finish. Let’s say there are 50 people in the queue. Now, the 50th person who is in the queue at 10:00 AM needs to wait till 10:50 AM for his order to be picked. Now, this is what it feels like as a customer who is very hungry :) and I can’t wait for so long, right.

Event-Driven Design: The Core Principle Behind Kubernetes Architecture

Sat, 24 Jan 2026 15:56:13 +0000

Note: This is a handwritten blog. In this blog, we should explore the event where the architecture of Kubernetes is discussed. It will be very short.

As you know, Kubernetes follows an event-driven architecture. The Kubernetes control plane heavily consumes events. But most distributed systems follow RPCs to trigger behavior, but Kubernetes does not.

Reason behind why Kubernetes is not built using RPCs:

Tight coupling: RPCs create strong dependencies between components. In Kubernetes, control plane components must remain loosely coupled to evolve and scale independently.
Poor failure handling: RPCs expect the caller and callee to be alive at the same time. In a distributed system like Kubernetes, transient failures are common and break this assumption.
Scalability limits: Synchronous RPC calls don’t scale well when thousands of objects and controllers are involved. They can easily become bottlenecks.

Let’s understand this scenario with one simple example. When you create a Deployment, the following happens:

Kubernetes-Operator on Anish Bista

Don’t Make Your Users Wait: Parallelism in Kubernetes Operators

The Restaurant Example#

Event-Driven Design: The Core Principle Behind Kubernetes Architecture