Event-Driven Actor Runtime

A non-confidential, case-study-style overview. Specifics are generalized.

Problem

Modeling thousands of independent devices — each with its own state, lifecycle, and stream of incoming events — as rows in a database and a pile of handlers led to tangled concurrency, race conditions, and logic that was hard to reason about per device. The system needed a unit of isolation that matched the problem: one device, one consistent state machine.

Decisions

• Adopted an actor-style model: each device maps to an isolated unit that owns its state and processes its events sequentially, removing intra-device races.
• Made every state transition event-driven and replayable, so behavior could be reconstructed and tested deterministically.
• Kept the runtime deliberately small — supervision, message routing, and lifecycle — rather than reaching for a heavyweight framework.
• Designed actor lifecycle (spawn, idle, passivate) around real device activity patterns to bound resource use.

Tradeoffs

• Sequential per-actor processing traded raw single-device throughput for correctness and simplicity — the right call given the concurrency it removed.
• A bespoke lightweight runtime meant owning code a framework might provide, in exchange for a small surface area and no impedance mismatch.
• Event-sourced transitions added storage and replay considerations but made the system debuggable and auditable.

Outcome

Per-device logic became simple to write and reason about, concurrency bugs largely disappeared, and the runtime scaled by adding isolated units rather than untangling shared state. Replayable transitions turned debugging production behavior into a deterministic exercise.

Technologies

TypeScript · actor model · event-driven / event-sourced design · supervision and lifecycle management · distributed-systems patterns.