Guided architecture tour · 6–8 min
Follow a stream of live events — Kinesis Data Streams
Plan how an app collects and processes a continuing stream of events.
This tour teaches architecture decisions. Its services are not provisioned in the emulator.
Your goal
Plan how an app collects and processes a continuing stream of events.
Why this matters
A game sends live activity events from many players. You will group related records, choose how readers keep their place, and make replay useful instead of harmful.
Words you will use
A stream is a continuing sequence of records. A partition key groups related data. A consumer reads records. A checkpoint records how far a consumer has processed.
How to proceed
Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.
1. Choose a meaningful key
Events from the same player need a meaningful sequence, while many players should share the stream’s capacity. Choose a partition key strategy.
What should guide the key?
Related ordering needs and a balanced spread of traffic.
Partition keys determine how records are assigned within the stream. Choose keys that support the ordering you need without concentrating too much traffic on one key. Measure hot spots rather than assuming equal traffic.
The stream has a deliberate grouping and load plan.
Related events → suitable partition key → stream records2. Keep track of progress
A consumer restarts after processing part of the stream. It needs a known point from which to continue rather than guessing what was completed.
What should it maintain?
Checkpoints tied to successfully processed records.
A checkpoint records processing progress. Store it at the appropriate point after successful work, using the consumer framework’s behavior correctly. Restart and failure tests reveal whether the app skips or repeats work.
The consumer has a recoverable position.
Process successfully → checkpoint → resume after restart3. Plan for replay and retention
The team wants to replay recent events after fixing a calculation. Records are retained for a configured period, and replay can repeat earlier side effects.
What does the design need?
A suitable retention period and repeat-safe processing.
Choose retention for the recovery window you need and plan for records outside it. Consumers can replay retained data, so calculations and writes must handle repeated events deliberately. A stream is not a permanent archive by default.
Replay has a defined window and safe processing behavior.
Retained records → deliberate replay → repeat-safe resultsPractice, then check your understanding
In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.
Read the official AWS documentation for service behavior and production details.