🇰🇷 한국어판 — Read this article in Korean: 통화 한 통도 놓치지 않는 법 — Luware가 Akka.NET 액터로 미션 크리티컬 음성 서비스를 지킨 방법

🖼️ Figure 0. (Hero) The actors holding up a mission-critical voice service — cartoon hero image

🎯 TL;DR — 3 lines

• Luware runs Nimbus, a Microsoft Teams-based contact center, handling millions of call minutes per month with zero downtime.

• Scattering call state across microservices led to distributed locking hell and race conditions — solved with **Akka.NET actors + cluster sharding + event sourcing**.

• The key mental shift: "one stateful object (an actor) owns one call in its entirety." The locks disappear, and the system "just works."

Introduction — A World Where a Single Dropped Call Is Unacceptable

Imagine calling a contact center. Agent connection, queuing, transfers, recording, and call analytics all interlock at millisecond granularity. What happens if the timing slips just once? The call drops. The customer gets angry, and the business loses trust.

This is the world that Nimbus, built by the Swiss company Luware, lives in. Nimbus is contact center software integrated into Microsoft Teams, and it

• processes millions of call minutes per month,
• serves more than 1,000 customers worldwide, and
• is expected to run 24/7 with zero downtime.

Based on the Luware case study published by Petabridge, this article walks through the wall Luware hit and how they climbed over it with the **Akka.NET actor model** — explained at a working developer's eye level. If actors are new to you, don't worry: we build up the concepts step by step.

1. The Problem — "You End Up in Distributed Locking Hell"

Initially, Luware managed call state across multiple stateless microservices. Information about a single call was scattered across service A, service B, and caches. That is exactly where the trouble began.

🖼️ Figure 1. Distributed locking hell vs. actors — the chaos of multiple services touching the same call state concurrently / the order of one actor owning a call outright

A quote from Luware engineer Jason Shave sums up the situation precisely: