Messaging Foundations
Decide which parts of a flow stay synchronous and which become async events, tell a queue from a pub/sub topic from a durable log by retention and replay, and pick a specific broker instead of reaching for Kafka by reflex.
Sync vs Async & When to Go Event-Driven
Async decouples in time, space, and synchronization at the cost of eventual consistency; keep the result-bearing or consistency-sensitive steps synchronous and make independent side effects events.
Queue vs Pub/Sub vs Log/Streaming
A queue distributes work and deletes on ack (no replay); pub/sub fans a copy to every subscriber; a log retains an ordered stream that many consumer groups read at their own offset and can replay.
Broker Technology Selection
Match the broker to the drivers (throughput, ordering, retention/replay, delivery, routing, ops budget); a log only when replay/throughput justify its ops, and sometimes no broker at all.
Kafka & the Log
Reason about Kafka like a staff engineer: why the append-only log gives throughput, why partitions are the atom of ordering and parallelism, how a wrong key breaks correctness, how rebalancing becomes latency, and how retention decides stream vs table.
Kafka Architecture Internals
Sequential writes, page cache, and zero-copy give throughput; durability is leader/follower ISR replication where durable means acks=all + min.insync.replicas>=2 + RF3.
Partitioning, Ordering & Keys
Kafka orders within a partition only, chosen by hash(key) mod N, so causally related events share a key; partition count is fixed up front, and a hot key trades ordering scope for throughput.
Consumer Groups, Rebalancing & Scaling
Group size is capped by partition count; commit-after-process gives at-least-once so handlers must be idempotent; cooperative rebalancing and static membership avoid stop-the-world, and you scale on lag.
Log Compaction, Retention & Tiered Storage
Delete-retention makes a replayable stream, compaction makes a rebuildable table/changelog with tombstones, tiered storage makes long retention cheap, and dedup must cover the replay window.
Delivery Guarantees
State a system's end-to-end delivery guarantee precisely and stop misusing 'exactly-once', make APIs and consumers idempotent so at-least-once delivery and client retries converge to one outcome, and build retry, dead-letter, and backpressure machinery that keeps a stream flowing without losing data or blocking a partition on one poison message.
Delivery Semantics: At-Most / At-Least / Exactly-Once
Ack timing sets the guarantee (commit-before-process is at-most-once, process-before-commit is at-least-once); exactly-once delivery over a network is impossible, so you convert at-least-once into effectively-once processing at the consumer, and Kafka EOS covers only a read-process-write loop inside Kafka.
Idempotency & Deduplication
Neutralize at-least-once duplicates with natural idempotency, state machines with expected-version checks, or a dedup store that saves the result (not a boolean) under an idempotency key; resolve the concurrent race with an atomic check-and-set and size the TTL to cover both the client-retry and broker-replay windows.
Retries, Dead-Letter Queues & Backpressure
Retry transient errors with capped exponential backoff plus jitter, send permanent failures and exhausted retries to an alerted redrivable DLQ, never retry in place on an ordered partition (use retry topics to avoid head-of-line blocking), and lean on the durable log as your backpressure buffer while autoscaling on consumer lag.
Stream Processing & Event Patterns
Design real-time stream pipelines that stay correct under late and out-of-order data, model state as an immutable event log you can replay and time-travel, and split write and read models with CQRS so each scales and is shaped for its own job without paying complexity you do not need.
Stream Processing: Windowing, Watermarks & State
Aggregate by event time (not processing time), use watermarks to bound lateness and fire windows, keep local state fault-tolerant via RocksDB plus checkpoints/changelogs for exactly-once state, and never drop late data silently.
Event Sourcing
Store immutable events as truth and fold them to derive state, bound replay with snapshots, guard writes with expected-version optimistic concurrency, correct by appending a compensating event (never editing), and use it only where audit/temporal value justifies the complexity.
CQRS & Read Models
Split commands (validated write model) from queries (denormalized projections built by idempotent event handlers), accept eventual consistency and handle read-your-writes explicitly, rebuild read models by replay, and do not drag in event sourcing unless you separately need it.
Schema Governance & Ops
Govern a shared event schema so many teams evolve it without breaking each other (compatibility modes, registry enforcement, the safe way to make a breaking change), and operate the messaging tier itself: replicate and ack so no acknowledged message is ever lost, monitor the signals that expose silent async failures, and size partitions, storage, and network for a million-message-per-second stream.
Schema Management & Evolution
An event schema is a versioned public contract enforced at produce time by a registry; evolve additively with defaults under a stated compatibility mode (which dictates deploy order), and make true breaks with upcasting, tolerant readers, or a new topic, never an in-place mutation.
Streaming Durability, HA & Observability
Prevent acknowledged loss with rack-aware RF3 plus acks=all plus min.insync.replicas=2 and clean leader election; make consumer lag the primary SLO alongside under-replicated partitions, DLQ depth, and end-to-end tracing; size partitions from throughput and storage from rate times size times retention times replication.