Actors, Supervision, Lebenszyklus
Das klassische Actor-Modell in idiomatischem TypeScript. Jeder Actor besitzt seinen eigenen State und verarbeitet Nachrichten eine nach der anderen — Du musst also nicht mehr über Locks und Race Conditions nachdenken. Wenn ein Kind abstürzt, entscheidet sein Elternteil, ob es neu gestartet, eskaliert oder gestoppt wird — Supervisionsbäume geben Dir Fehlertoleranz als strukturelle Eigenschaft, nicht als nachträgliches try/catch.
Cluster + Sharding
Lass dasselbe Actor-System über viele Nodes hinweg laufen. Mitglieder finden sich per Gossip, der Failure Detector markiert unerreichbare Peers, und Split-Brain-Resolver entscheiden, wer eine Partition überlebt. Sharding verteilt langlebige, statusbehaftete Entitäten über den Cluster, balanciert beim Hinzufügen oder Entfernen von Nodes neu und merkt sich, welche Entität wo lebt — so läuft ein Neustart sauber weiter.
Event Sourcing + Persistenz
Mach Actor-State absturzsicher, indem Du die Events aufzeichnest, die
dazu geführt haben, statt des States selbst. PersistentActor spielt
sein Event-Log beim Start wieder ab; DurableState schreibt einen
einzelnen Snapshot, wenn die vollständige Historie nicht nützlich ist.
Journals sind steckbar — in-memory für Tests, SQLite für Single-Node-
Produktion, Cassandra oder S3 für Skalierung — mit erstklassigem
Snapshotting und Projektionen für Read-Side-Views.
Verteilte Daten (CRDTs)
Geteilter State über den Cluster ohne Koordinator. Acht konfliktfreie replizierte Datentypen — Counters, Registers, Sets, Maps — die immer zum gleichen Wert konvergieren, egal in welcher Reihenfolge Updates kommen. Wähle Quorum Reads + Writes für strikt-ish Konsistenz oder akzeptiere Gossip-Propagierung, wenn Du sie nicht brauchst. Ein durables Backend bewahrt den State über Neustarts hinweg.
Integrationen
Die Welt außerhalb des Actor-Systems, hinter einer konsistenten Form.
HTTP mit einer Directive-Style-Route-DSL auf Fastify-, Express- oder
Hono-Backends. Message Broker — Kafka, MQTT, AMQP, NATS, Redis
Streams, gRPC, SSE, WebSocket, raw Sockets — alle umhüllt von einer
gemeinsamen BrokerActor-Basis mit Reconnect, Buffering und Fan-out
von Haus aus. Cache + Serialisierung sind steckbare Abstraktionen.
Observability + Testing
Produktionsreife Sichtbarkeit von Tag eins. Stock-Metriken für jeden Actor, Mailbox-Tiefe, Gossip-Lag, Restart-Counter — exportiert über Prometheus oder OpenTelemetry. Per-Message-Tracer-Spans, sodass eine Anfrage mit einer Trace-ID durch Deinen Cluster fließt. Management- HTTP-Endpunkte zeigen den Cluster-Status. TestKit liefert deterministische Multi-Node-Tests mit einem manuellen Scheduler für Zeitkontrolle.
Zwei End-to-End-Beispiel-Apps leben im Repo, jede mit sechs
austauschbaren Frontends (Plain HTML, Lit, Angular, React, Next.js,
SvelteKit), die dasselbe WebSocket-Protokoll mit einem geclusterten
Backend sprechen. Klonen, bun examples/<sample>/backend/main.ts,
Frontend im Browser öffnen und ein echtes laufendes Actor-System
herumstochern.
actor-ts ist pre-1.0. Die API-Oberfläche ist breit und im
internen Einsatz produktionserprobt, aber bis 1.0 geschnitten ist,
können zwischen Minor-Versionen Breaking Changes landen. Eine
bestimmte Minor-Version in Deiner package.json zu pinnen und das
CHANGELOG
vor dem Upgrade zu lesen, ist während dieser Phase das sichere
Vorgehen.
