How to Manage State in Apache Kafka
summary
Uses Kafka for transport and storage but finds the event log is not a substitute for a state store, so the team cycles through approaches: reading the log from start (unworkable at scale), caching (loses durability), sending full-state messages (durable but causes 9 MB messages and heavy CPU work), and early Kafka Streams tests (rebalance recovery problems). Final solution combines a database-backed golden copy with CDC from DB to publish lightweight triggers; services see up to 40 minutes startup reduced to seconds.
AI-written summary · about
chapters (16)
- 0:00Introduction and context
- 3:03William Hill use case
- 6:56State in event logs vs databases
- 9:27Golden copy of state necessity
- 11:55Abramson’s law of event logs
- 13:03Event log as state store myth
- 16:33Problems with caching and metadata
- 17:15Full state messages approach
- 21:57Drawbacks of full state messages
- 22:18Attempt with Kafka Streams
- 24:25Return to state stores
- 27:57State store ownership models
- 30:22Change data capture pattern
- 33:13Hardware limitations impact
- 37:52Cultural lessons and ops collaboration
- 38:54Summary and key takeaways
related talks
29mApache Kafka and the Next 700 Stream Processing Systems
33mKafka streams at scale
17mOvercome By Events - Apache Kafka And Event-oriented Architecture
53mDemystifying Kafka
31mEvent Streaming with Kafka Streams
38mRe-architecting Apache Kafka for the Cloud
27mNo More Silos: Integrating Databases and Apache Kafka
13mKeynote – Jay Kreps
