Kinesis Data Streams is used for real-time streaming data.
Examples: - IoT sensor data - Clickstream data - Logs - Financial transactions
Data is stored in Shards.
Think of a shard as an independent lane that stores and serves records.
Every shard provides fixed capacity.
Each shard supports:
More shards = - More write capacity - More read capacity - More parallel processing
Every record must have a Partition Key.
Kinesis hashes the partition key to decide which shard stores the record.
Example:
Customer123
Customer123
Customer123All go to the same shard.
If one partition key receives much more traffic than others,
→ One shard becomes overloaded.
This causes
Fix:
Example:
Instead of
Customer123Use
1-Customer123
2-Customer123
3-Customer123Traffic spreads across multiple shards.
When traffic increases,
you can increase shards.
Example
4 shards
↓
8 shardsImportant for the exam:
Lambda automatically detects new shards.
No redeployment.
No configuration change.
No manual updates.
Kinesis guarantees ordering
ONLY inside a single shard.
Not across shards.
Example
Shard A
1
2
3Always processed in order.
Shard B
A
B
CAlso ordered.
But
1
A
2
Bcan happen because shards are processed independently.
Lambda polls Kinesis automatically.
Important rules:
Example
3 shards
↓
3 concurrent Lambda executionsNormally
1 Lambda per shardYou can increase the Parallelization Factor.
Example
5 shards
Parallelization Factor = 2
↓
Up to 10 concurrent Lambda executionsUseful when consumers fall behind.
Iterator Age tells you
How far behind the consumer is.
Small value
✅ Consumer is keeping up.
Growing value
❌ Consumer is too slow.
Fixes:
Normally,
all consumers share the shard's read throughput.
With Enhanced Fan-Out,
each consumer gets
Best when
Kinesis supports encryption at rest.
Enable
Server-Side Encryption (SSE)
using
AWS KMS
You can use
Exam answer:
Enable SSE with a KMS Customer Managed Key.
Means a shard exceeded its capacity.
Common fixes:
✅ Add more shards
✅ Use better partition keys
✅ Use random partition key prefixes
Do NOT think of:
Those do not solve hot shards.
Exactly the same idea as a hot shard.
One partition key receives most writes.
Symptoms:
Fix:
Write Sharding
Example
Instead of
Device123Use
Device123-1
Device123-2
Device123-3Reads combine results.
For
Partition Key + Sort Key
Always use
Query
Example
CustomerId = 100
OrderDate BETWEEN A AND BNever use Scan unless absolutely necessary.
✅ Automatically detects new shards
✅ Ordered within a shard
❌ Not ordered across shards
Consumer is slow.
Fix:
Dedicated
2 MB/sec per consumer per shard
One partition key sends too much traffic.
Fix:
Enable
Server-Side Encryption + KMS CMK
Need Partition Key + Date Range?
✅ Query
❌ Scan