Event-based Architecture & Implementations with Kafka & Atom
summary
Compares Kafka and Atom with concrete tradeoffs: Kafka stores records forever, offers consumer groups and partition ordering guarantees, needs Zookeeper/replicated disks and a cluster but scales horizontally; Atom uses HTTP feeds, conditional GET caching and content negotiation so consumers poll efficiently without extra infra. Shows a runnable Docker/GitHub order-invoice-delivery demo (build + create + run ≈ three commands) and argues event sourcing is a local persistence choice not a shared service, plus idempotency handles duplicate delivery.
AI-written summary · about
chapters (15)
- 0:00Intro
- 1:44Independent Systems Architecture
- 8:01Events - Communication between Bounded Contexts
- 9:08Event: Decoupling
- 15:41Events: Conclusion
- 17:13THE END IS NEAR
- 17:51Inconsistencies Either delivery without invoice
- 21:21Persistence • Responsibility of the microservices
- 24:47Kafka Topics Topics have a name
- 27:49Kafka Replication ·N Replicas (configurable)
- 31:00Data Data is copied into Invoice / delivery database
- 32:16Kafka Conclusion - Provides access to old events
- 39:13Alternative Roll your own format
- 40:06Atom Conclusion Con provides access to old events if they are stored anyway.
- 42:56Conclusion Most important: Getting the split right!
related talks
01h 00mReacting to an Event-Driven World
46mState or events? Which shall I keep?
42mCreating event-driven microservices: the why, how and what
45mCommon quandaries implementing your first Event Driven Architecture
54mReacting to an Event-Driven World
31mDemystifying Event-Driven Architectures
48mEvent-Driven Architecture – Benefits and Pitfalls
17mOvercome By Events - Apache Kafka And Event-oriented Architecture