CloudArcade

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.

Play this architecture 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 records

2. 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 restart

3. 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 results

Practice, 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.

Continue with another AWS learning guide