Streaming And Messaging Systems
Overview
Use this skill for continuous data movement and real-time processing. It helps agents design safe event pipelines around brokers and stream processors such as Kafka, Kinesis, and Flink, with attention to ordering, state, replay, schema evolution, and delivery guarantees.
When to Use
- designing or modifying
Kafka topics, consumers, or stream processors
- using
Kinesis for event ingestion or streaming delivery
- implementing
Flink jobs or stateful stream transformations
- defining near-real-time pipelines, windows, watermarks, and replay behavior
- handling schemas and contracts for event-driven systems
Do not use this when the workload is purely batch and does not require streaming semantics.
Workflow
Define the event contract.
Include:
- event key
- schema and versioning
- ordering expectations
- delivery guarantees
- retention and replay policy
Choose the right platform role.
Kafka: durable event backbone and broad ecosystemKinesis: AWS-native streaming ingestion and transportFlink: stateful stream processing and event-time logic
Design for state and late data.
Account for:
- watermarks
- windows
- deduplication
- exactly-once or at-least-once semantics
- checkpointing and recovery
Make consumer behavior observable.
Lag, failed checkpoints, poison messages, schema drift, and dead-letter handling should be planned, not discovered in production.
For production Kafka hardening, load kafka-resilience-and-schema-evolution.
For live lag or broker metadata before changes, load mcp-data-observability-integration.
Treat replay as a first-class operation.
Reprocessing events should not depend on manual guesswork.
Common Rationalizations
| Rationalization |
Reality |
| "Streaming just means faster batch." |
Streaming introduces ordering, state, replay, and time semantics that batch systems do not have. |
| "We can ignore schema evolution because events are small." |
Event size does not reduce contract risk; schema drift can break many downstream consumers. |
| "Exactly-once is automatic." |
Delivery semantics depend on end-to-end design, state handling, sinks, and replay behavior. |
Red Flags
- no explicit event contract or key strategy
- replay and retention are undefined
- time semantics are assumed instead of specified
- consumer lag and dead-letter strategy are missing
- stateful processing has no checkpoint or recovery plan
Verification
1---2name: streaming-and-messaging-systems3description: Guides agents through event streaming and real-time data pipeline design. Use when working with Kafka, Kinesis, Flink, stream processing, windowing, stateful consumers, or near-real-time publish flows.4---56# Streaming And Messaging Systems78## Overview910Use this skill for continuous data movement and real-time processing. It helps agents design safe event pipelines around brokers and stream processors such as `Kafka`, `Kinesis`, and `Flink`, with attention to ordering, state, replay, schema evolution, and delivery guarantees.1112## When to Use1314- designing or modifying `Kafka` topics, consumers, or stream processors15- using `Kinesis` for event ingestion or streaming delivery16- implementing `Flink` jobs or stateful stream transformations17- defining near-real-time pipelines, windows, watermarks, and replay behavior18- handling schemas and contracts for event-driven systems1920Do not use this when the workload is purely batch and does not require streaming semantics.2122## Workflow23241. Define the event contract.25 Include:26 - event key27 - schema and versioning28 - ordering expectations29 - delivery guarantees30 - retention and replay policy31322. Choose the right platform role.33 - `Kafka`: durable event backbone and broad ecosystem34 - `Kinesis`: AWS-native streaming ingestion and transport35 - `Flink`: stateful stream processing and event-time logic36373. Design for state and late data.38 Account for:39 - watermarks40 - windows41 - deduplication42 - exactly-once or at-least-once semantics43 - checkpointing and recovery44454. Make consumer behavior observable.46 Lag, failed checkpoints, poison messages, schema drift, and dead-letter handling should be planned, not discovered in production.47 For production Kafka hardening, load `kafka-resilience-and-schema-evolution`.48 For live lag or broker metadata before changes, load `mcp-data-observability-integration`.49505. Treat replay as a first-class operation.51 Reprocessing events should not depend on manual guesswork.5253## Common Rationalizations5455| Rationalization | Reality |56| --- | --- |57| "Streaming just means faster batch." | Streaming introduces ordering, state, replay, and time semantics that batch systems do not have. |58| "We can ignore schema evolution because events are small." | Event size does not reduce contract risk; schema drift can break many downstream consumers. |59| "Exactly-once is automatic." | Delivery semantics depend on end-to-end design, state handling, sinks, and replay behavior. |6061## Red Flags6263- no explicit event contract or key strategy64- replay and retention are undefined65- time semantics are assumed instead of specified66- consumer lag and dead-letter strategy are missing67- stateful processing has no checkpoint or recovery plan6869## Verification7071- [ ] Event schema, keys, retention, and replay rules are defined72- [ ] Platform responsibilities are clear across broker and processor layers73- [ ] Time semantics, state, and recovery design are explicit74- [ ] Operational visibility exists for lag, failures, and bad records
vaquarkhan