Event Streams in Action Real-time event systems with Kafka and Kinesis (Alexander Dean, Valentin Crettaz)（Z-Library）

【One-Line Pitch】 A hands-on guide to building real-time, event-driven systems around a unified log, using Kafka and Kinesis as the concrete tooling. Best for backend and data engineers with Java, Scala, or Python experience who want to move from batch thinking to continuous event processing. 【Book Arc】 - **Opening (~0%–15%)**: Frames events as a first-class concept, showing how logging, data warehouses, monitoring, and web analytics are already event streams in disguise, then introduces the unified log as the architectural glue that replaces point-to-point integrations. - **Early (~15%–30%)**: Gets concrete with the unified log: modeling events as JSON, standing up Kafka, and writing/reading events through topics, using a fictional e-commerce retailer (Nile) as the running example. - **Early–Middle (~30%–45%)**: Builds a first stream-processing app in Java — a pass-through worker, then a single-event processor that validates, enriches (e.g., geo-location), and routes events to good/bad topics; then mirrors the same ideas in Amazon Kinesis with shards, iterators, and boto. - **Middle (~45%–60%)**: Moves from single-event to multi-event processing — aggregation, pattern matching, sorting — and the stateful stream processing that windows and batches require. - **Late (~60%–85%)**: Shifts to data engineering concerns: schemas, archiving events, railway-oriented (error-routing) processing, and commands as distinct from events. - **Ending (~85%–100%)**: Turns to analytics, contrasting analytics-on-read with analytics-on-write and how each shapes the pipeline. (Excerpts do not cover the final chapters in detail.) 【Key Takeaways】 - **The unified log is the architectural centerpiece** (Opening): it replaces a mesh of point-to-point integrations with a single append-only backbone that systems read from and write to, cutting connection complexity dramatically. - **Events are best modeled as subject-verb-object** (Early): a consistent event grammar (who did what, when, to which object) makes streams queryable and schemas stable across producers. - **Single-event processing is the on-ramp; multi-event processing is the real work** (Early–Middle): validation, enrichment, and filtering are tractable, while aggregation, pattern matching, and sorting introduce state and windows and are "significantly more complex." - **Route failures, don't drop them** (Middle): the good/bad/warning topic pattern (railway-oriented processing) keeps bad data observable and reprocessable rather than silently lost. - **Kafka and Kinesis share concepts but differ in mechanics** (Middle): topics vs. shards, consumer groups vs. shard iterators, and Kinesis's per-shard read/write limits shape how you scale. - **Reading does not consume** (Middle): events persist in the log after being read, so multiple applications can independently replay the same history — the basis for reprocessing and backfill. - **Schemas and archiving are first-class data-engineering concerns** (Late): without deliberate schema management and event archiving, event systems rot as producers and consumers drift. - **Analytics-on-read vs. analytics-on-write is a design fork** (Ending): where you compute aggregates determines latency, flexibility, and storage cost. 【Reading Tips】 - Deep-read Part 1 (chapters on the unified log, Kafka, Kinesis, stateful processing) — it carries the conceptual payload; skim the setup/CLI walkthroughs if you already run Kafka or Kinesis. - Follow the Nile example end-to-end at least once; the incremental build from pass-through worker to validating/enriching processor is where the mental model clicks. - Treat the code listings as scaffolding, not reference code — the book reformats and trims them, so download the publisher's source for anything you intend to run. - Pay attention to the Kafka/Kinesis comparison points (shards, iterators, limits); this is where operational intuition is built. - If you only have time for one idea, take away the unified log pattern and the good/bad/warning routing discipline. 【Coverage Limits】 This guide is based on stratified excerpts covering roughly the first half of the book plus the table of contents; the later data-engineering and analytics chapters (schemas, archiving, commands, analytics-on-read/write) are described only at the level their titles and framing allow.