Event-Driven Architecture learning path: everything to study, topic by topic

Treating an event as an immutable record of something that happened — the single source of truth shared across services rather than a transient signal hidden behind an API

The difference between a durable, replayable, append-only event stream (log) and a traditional message queue where messages are consumed and removed

Choosing between thin event-notification messages that signal a change and event-carried state transfer that includes the full data the consumer needs

Modeling event streams as topics: granularity, one-entity-per-topic guidance, single-writer ownership, and how topic boundaries map to business entities

The producer/consumer model: producers write to topics, consumers read at their own pace via offsets, consumer groups, and the decoupling this creates between sides

Defining explicit, serializable event schemas with Avro or Protobuf so producers and consumers share a strongly typed contract rather than implicit JSON shapes

Evolving event schemas safely over time using backward, forward, and full compatibility rules so old and new producers and consumers can coexist

Treating a published event stream as a long-lived public data contract with explicit ownership, semantics, and quality guarantees that consumers can depend on

Using a central schema registry to store, version, and enforce compatibility of event schemas so producers cannot publish incompatible changes

Processing each event independently — transforms, filters, and enrichments that require no memory of prior events and scale horizontally with ease

Processing that accumulates state across events — aggregations, joins, windowing — backed by a local state store and changelog for fault tolerance

How partition keys determine ordering guarantees and parallelism: events sharing a key stay ordered within a partition, while cross-partition ordering is not guaranteed

Building queryable materialized views by consuming an event stream and maintaining a local table that always reflects the latest state for fast reads

Persisting state as an ordered log of domain events rather than as current rows, reconstructing state by replaying events and enabling full historical audit

Command Query Responsibility Segregation: separating the write model that validates and emits events from independently optimized read models built from those events

Atomically writing business state and an outbox event row in one local transaction, then relaying outbox rows to the event stream to avoid dual-write inconsistency

Building and rebuilding read-side projections by folding events into purpose-built views, and replaying from the start to recreate a projection after a schema change

Coordinating multi-service workflows by reacting to events (choreography) versus a central coordinator issuing commands (orchestration), and the trade-offs of each

Managing a long-running distributed transaction as a sequence of local transactions, each publishing an event that triggers the next step or a compensating action on failure

Designing compensating transactions that semantically undo completed saga steps when a later step fails, since committed local transactions cannot be rolled back

Reasoning about at-most-once, at-least-once, and exactly-once semantics, and why at-least-once delivery plus idempotent consumers is the pragmatic path to effectively-once processing

Making consumers safe under duplicate and out-of-order delivery using idempotency keys, deduplication, and upsert semantics so reprocessing causes no side-effect drift

Isolating poison messages that repeatedly fail processing into a dead-letter stream so they do not block the partition, plus retry, alerting, and reprocessing strategy

Accepting that derived state across services converges over time, reasoning about replication lag and read-your-writes anomalies, and designing UX and APIs that tolerate them

Exploiting durable event streams to replay history — backfilling new consumers, rebuilding state after bugs, and bootstrapping new services from the retained log