Event-Driven Architecture
Studies in this cluster, in series order. Each one keeps its own URL.
Messaging
Kafka, event-driven architecture, outbox and CQRS, WebSockets, MQTT, and queues you can defend in interviews.
Event-Driven Architecture
6 studies- 1.Event-Driven Architecture — Sync vs Events, Patterns & TradeoffsEvent-driven architecture publishes facts that already happened. This hub maps sync versus events, notification versus carried state versus sourcing, and where CQRS, the outbox, ordering, and failure modes sit.
- 2.Event Types — Notification, Event-Carried State Transfer & Event SourcingNotification, event-carried state transfer, and event sourcing are different contracts. Payload richness decides coupling, races, and whether the log is the source of truth.
- 3.CQRS — Commands, Queries, Projections & ConsistencyCQRS splits commands that change state from queries shaped for screens. In an event-driven system the read side is usually a projection, and lag is an SLO rather than a stuck write.
- 4.Transactional Outbox, Inbox & Consumer IdempotencyA dual-write commits the database and publishes as two steps, so one can succeed alone. The outbox makes the intent to publish part of the local commit. The inbox makes at-least-once delivery safe.
- 5.Ordering, Partitions, Poison Messages & Retry/DLQ StrategyMost event-driven flows need order per entity, not global order. Partitions buy parallelism. Bounded retries and a dead-letter path keep one poison message from stalling that entity.
- 6.EDA Failure Modes — Dual Writes, Schema Drift & Fan-out Blast RadiusEvent-driven systems fail in known ways: dual-write loss or ghosts, schema changes that break a fleet, and one poison event amplified across every consumer. Containment is outbox, compatible rollout, and per-consumer isolation.