Leveraging the Actor Model in Financial Transaction Systems
summary
Claims that using Kafka plus an actor-style handler eliminates DB locking for transfers, shows a working design and tradeoffs: Postgres select‑for‑update causes 500 active transactions at 100 ops/s with 5s processing, local locks fail across nodes, distributed locks bring ordering and timeout pain. Built a Kafka‑backed actor: state stored in DB, outbox pattern to avoid double writes, messages partitioned by transfer ID so one consumer processes a transfer at a time, with dead‑letter handling; prototype runs and scales up to partition limits.
AI-written summary · about
chapters (9)
- 0:00Introduction and Speaker Background
- 0:55Agenda Overview
- 1:32Understanding Financial Transactions
- 3:35Technical Problem: Lost Update
- 6:03Traditional Approaches to Solve Lost Update
- 17:13Introduction to Asynchronous Processing
- 22:46Kafka Basics and Implementation
- 30:00Implementing the Actor Model
- 39:40Conclusion and Final Thoughts
related talks
59mBuilding Data Intensive Microservices with Apache Kafka
43mIntroduction to Akka Actors: Concurrency and Distributed Systems for the JVM
27mOptimize Your API with Event-Driven Microservice Architecture.
50mMoving from legacy to event-driven with Kafka
21mHow Apache Kafka® Generates Value In Retail With Confluent
51mStreaming Platforms in Event-Driven Systems: Patterns, Pitfalls, and Performance
30mChange Data Streaming Patterns in Distributed Systems
31mEvent Streaming on Rails