How do we approach event streaming at Revolut?
summary
Revolut builds its own event streaming on Postgres rather than Kafka: events are appended immutably to a partitioned Postgres event log (monthly partitions, table >4–5 TB), propagated via Postgres NOTIFY/LISTEN, served by two stateless Ktor instances (Netty, Kotlin coroutines) exposing SDKs and WebSocket streams. Producers write model change and event in one DB transaction, marking a local journal; delivery is at-least-once via local journal + reconciler that batches retries. System meets production scale, feeds Kafka for analytics, and targets p99 <20 ms.
AI-written summary · about
chapters (16)
- 0:00Introduction and speaker intro
- 1:29Revolut and event streaming context
- 4:43Requirements for event streaming
- 12:04Solution design overview
- 18:22Real-world use cases
- 22:20Handling distributed transactions
- 25:35Ensuring data consistency
- 33:14Reconciliation and fault tolerance
- 36:35Achieving delivery guarantees
- 37:18PostgreSQL optimizations
- 39:02Scalability and performance
- 40:06Low-latency strategies
- 42:58Client SDK and observability
- 45:10Subscription and streaming mechanics
- 47:41Future improvements
- 50:31Q&A and closing
related talks
30mEvent Streaming and the Future of Applications
35mEvent sourcing after page 1: How we built a cloud native bank
37mReactive Architecture on AWS: from 0 to 1.6M events/minute
18m"Kafka's Metamorphosis"
27mKeynote II: Kafka and the Rise of Event-Driven Microservices
44mThe Art and Benefits of Computing Eventfully
53mBuilding Event Driven Services with Apache Kafka and Kafka Streams
50mIntroduction to Apache Kafka