<aside> 📞

Series follow-up — continues from One Click Spawns a Phone Number, and That Call Rings in Discord: Building a Vonage Voice Bridge with Akka.NET Actors.

</aside>

🎯 Four-line summary

• Kubernetes decides where a process (pod) runs. An Akka.NET cluster decides which node the stateful objects (actors) inside that process live on, and how they migrate. These two are not competitors — they operate at different layers. This article is the record of stacking both layers onto one system.

• A dedicated seed node (lighthouse), cluster sharding, cluster singleton, and state externalization — the four concepts we actually needed to distribute actors, followed through working code. Including where remoting breaks inside containers, how to advertise a pod IP, and a measured timeline showing recovery on another node in about 4 seconds after a node died — and finally how we deleted that seed node altogether.

• Holding state has a price. For a stateless service the marginal cost of an idle customer is zero; for a stateful one it is not. We compare pods, threads and actors as the unit of isolation across the range of 1 brand → 5,000 brands, and work out where the cost actually explodes in a small-business distribution where "most brands are asleep" (the answer: not the actors, but the connections the actors hold).

• And one distinguishing feature of this system: self-monitoring. kubectl top tells you how many pods are up, but it will never tell you how many brand actors are living on which node. So we made actors ask other actors — and folded the Kubernetes API into the same screen.

<aside> 🎨

[Image #1] Hero: an actor map drawn on a layer above the pods · file: 2026-09-10-akka-k8s-01-hero.png

</aside>

Prologue — What the last article promised, and where things honestly stand

In the previous article we followed a journey: minting a phone number as code with Vonage, forking that call's audio over a WebSocket, and pulling it all the way into a Discord voice channel. It ended with this note — "The voice path is not actors yet. But the chat fan-out in the same codebase already is. Luware has proven where the design of 'one call = one actor' leads."

Let me be precise about what that article was. It was a proof of concept during product development. It had two goals: ① how fast can we acquire a phone number for voice calls (→ with a developer-first CPaaS like Vonage, instantly, via API), and ② can a customer's inbound channel actually be wired into Discord's voice feature (→ it can). Both came back "yes," and that was the full scope of that piece.

The product then chose a different order. Today TalkBridge (talkbridge.io) has launched as a product that connects chat-based customer support over KakaoTalk consultation first, and voice integration is not in the product yet. The validation stands; the shipping comes later. Blur that distinction in a technical article and nothing else in it can be trusted either.

What did move forward is the part we filed under "someday." The chat gateway's actors were distributed as an Akka.NET cluster, and that cluster ran natively on Kubernetes (AKS) pods. That is what this article is about — not a product pitch, but a technical record of which concepts were required to distribute the actor model, and what we split between Kubernetes and ourselves.

So why only now? — The place where the learning curve used to be

Honestly, we didn't skip this because we didn't know it. Kubernetes, and cluster topologies that distribute stateful services — the concepts had been familiar for a long time. The reason we never built one was the learning curve. How to bring up a seed node, who survives when the network partitions, where state lives, how that state is handed over during a deploy — designing and operating all of that ourselves looked more expensive than what we'd get out of it.

So, like most teams, we chose two things.

• Leave clustering and state machinery to a cloud PaaS. Managed queues, managed caches, managed databases. All the state lives over there and we don't touch the inside of it.
• Design services to be stateless wherever possible. Treat pods as parts that may die at any moment, and re-read whatever state you need from the outside every time.

That choice was not wrong. But its limits were clear. A web service built this way does not hold its own state, so whatever it does, it ends up processing as if calling an external service. Conversation context, an in-flight workflow — fetched from the outside, judged, pushed back out, every single time. And that "outside" is exactly the centralized bottleneck: everyone hammers the same DB, the same cache, the same queue.