--- title: Day 19/30 AWS System Design Patterns | daily.dev description: A system design scenario involving Amazon Kinesis Data Streams explores why a dashboard consumer falls behind during peak load despite all shards being under... canonical: https://daily.dev/posts/day-19-30-aws-system-design-patterns-bamc3lvms twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Day 19/30 AWS System Design Patterns | daily.dev og:description: A system design scenario involving Amazon Kinesis Data Streams explores why a dashboard consumer falls behind during peak load despite all shards being under... og:url: https://daily.dev/posts/day-19-30-aws-system-design-patterns-bamc3lvms og:image: https://api.daily.dev/og/posts/bAMC3lvMS.png og:image:alt: Day 19/30 AWS System Design Patterns og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Day 19/30 AWS System Design Patterns **[Joud Awad](https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh)** · [@joudawad](https://daily.dev/joudawad) · 2 min read · 72 upvotes · 28 comments ## Summary A system design scenario involving Amazon Kinesis Data Streams explores why a dashboard consumer falls behind during peak load despite all shards being under the 2 MB/s throughput limit. With 8 shards and three consumers using the standard GetRecords API, the key insight is that the 2 MB/s per-shard read limit is shared across all consumers polling that shard — meaning each of the three consumers effectively gets only ~667 KB/s per shard, while each shard produces 1.5 MB/s. This causes the dashboard consumer to fall behind, even though no individual shard appears overloaded. ## Content A Kinesis Data Stream _(real-time stream, 2 MB/s + 5 transactions/sec read limit per shard — shared across all consumers using standard GetRecords)_ ingests clickstream events for a real-time analytics platform. The stream has 8 shards. Three consumer applications read from it: an anomaly detector, a session aggregator, and a dashboard feed. All three use the standard `GetRecords` API via polling. At peak, the stream receives 1.2 million events per hour across all shards. Each shard produces roughly 150,000 records per hour — about 1.5 MB/s of data, within the 2 MB/s read limit per shard. The dashboard feed consumer starts falling behind. Its `IteratorAgeMilliseconds` metric climbs to 45 seconds during peak hours. The anomaly detector and session aggregator are keeping up fine. The team checks: no single shard is over the throughput limit. Total read consumption is 1.8 MB/s per shard — across all three consumers combined. Per-shard read limit is 2 MB/s. They are under the limit. Why is the dashboard consumer falling behind? A) The dashboard consumer's Lambda function _(serverless compute)_ is undersized — it cannot process records fast enough and is falling behind at the application level; but `IteratorAgeMilliseconds` climbing during peak while the other two consumers are fine points to a read throughput problem, not a processing speed problem B) All three consumers share the 2 MB/s per-shard read limit — with three consumers polling the same shard via standard GetRecords, each gets roughly 667 KB/s; a shard producing 1.5 MB/s but delivering only 667 KB/s to one consumer means that consumer falls behind C) The dashboard consumer needs its own dedicated shard _(shards are the unit of write partitioning — all consumers read from all shards; you cannot assign a shard to a single consumer)_ — shared shards cause head-of-line blocking between consumers D) The dashboard consumer should use Kinesis Firehose _(managed delivery pipe, buffers records 60s–900s before delivering to S3/Redshift — not a real-time consumer API)_ instead of reading directly from the Data Stream Answer in the comments. #EventDriven #SystemDesgin #AWS #Serverless #Architecture ## Community discussion Top comments from developers on daily.dev. **@pdfopsdev** · 3 upvotes > yep, that shared 2MB/s cap per shard is exactly why AWS added enhanced fan-out, each consumer gets its own dedicated 2MB/s pipe over HTTP/2 push instead of splitting the shared GetRecords budget. costs more per consumer-shard but it's the actual fix instead of over-provisioning shards. **@joudawad** · 3 upvotes > The answer is B. > > Kinesis Data Streams _(real-time stream)_ enforces a 2 MB/s and 5 transactions/second read limit per shard — and this limit is shared across all consumers reading from that shard using the standard `GetRecords` API. With three consumers polling the same shard, each consumer's effective read throughput is throttled to roughly one-third of the shard's capacity. Each individual consumer is getting around 600 KB/s from a shard producing 1.5 MB/s. That consumer will fall behind. > > The correct fix is Kinesis enhanced fan-out _(dedicated 2 MB/s read pipe per registered consumer —... **@trevorsuna** · 2 upvotes > B is the key here: the limit is shared per shard, not granted separately to each polling consumer. Enhanced fan-out would give the dashboard its own 2 MB/s read pipe, but I’d still watch IteratorAge alongside processing duration so a slow Lambda doesn’t hide behind the same symptom. **@mdshafinahmed** · 2 upvotes > GO ahead brother. **@webkmsyed** · 1 upvotes > Superb @joudawad ! I salute to your consistency! ## Similar posts on daily.dev - [Scaling StreamHub: Transitioning from Kinesis to Kafka for 145 Billion Daily Events](https://daily.dev/posts/scaling-streamhub-transitioning-from-kinesis-to-kafka-for-145-billion-daily-events-mjsieq3rp) · Atlassian · 1 upvotes · 0 comments - [AWS Kinesis vs Kafka: Choosing the Right Streaming Platform](https://daily.dev/posts/aws-kinesis-vs-kafka-choosing-the-right-streaming-platform-fhlmf8lir) · BigData Boutique blog · 6 upvotes · 0 comments - [Scaling a Financial Reconciliation Pipeline With Serverless](https://daily.dev/posts/scaling-a-financial-reconciliation-pipeline-with-serverless-gynvqfhrg) · Cloud Native Now · 0 upvotes · 0 comments --- Tags: [#aws](https://daily.dev/tags/aws), [#career](https://daily.dev/tags/career), [#serverless](https://daily.dev/tags/serverless) [View this post on daily.dev](https://daily.dev/posts/day-19-30-aws-system-design-patterns-bamc3lvms) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"DiscussionForumPosting","mainEntityOfPage":"https://daily.dev/posts/day-19-30-aws-system-design-patterns-bamc3lvms","headline":"Day 19/30 AWS System Design Patterns","text":"A system design scenario involving Amazon Kinesis Data Streams explores why a dashboard consumer falls behind during peak load despite all shards being under the 2 MB/s throughput limit. With 8 shards and three consumers using the standard GetRecords API, the key insight is that the 2 MB/s per-shard read limit is shared across all consumers polling that shard — meaning each of the three consumers effectively gets only ~667 KB/s per shard, while each shard produces 1.5 MB/s. This causes the dashboard consumer to fall behind, even though no individual shard appears overloaded.","url":"https://daily.dev/posts/day-19-30-aws-system-design-patterns-bamc3lvms","datePublished":"2026-08-08T17:58:43.571Z","dateModified":"2026-09-13T20:56:17.476Z","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0","description":"Principal Solution Architecture ","worksFor":{"@type":"Organization","name":"Metalab","logo":"https://www.google.com/s2/favicons?domain=metalab.com&sz=128"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":86250}},"image":"https://media.daily.dev/image/upload/s--X7T_KwPd--/f_auto/v1786211924/posts/bAMC3lvMS?_a=BAMAMicg0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":72},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":28}],"comment":[{"@type":"Comment","text":"yep, that shared 2MB/s cap per shard is exactly why AWS added enhanced fan-out, each consumer gets its own dedicated 2MB/s pipe over HTTP/2 push instead of splitting the shared GetRecords budget. costs more per consumer-shard but it’s the actual fix instead of over-provisioning shards.","datePublished":"2026-08-08T18:06:59.933Z","url":"https://daily.dev/posts/bAMC3lvMS#c-v6QxEtH4c","author":{"@type":"Person","name":"PDFops","url":"https://daily.dev/pdfopsdev","image":"https://media.daily.dev/image/upload/s---8isRBKc--/f_auto/v1782922291/avatars/avatar_orjMeK8QKaaVZwGq7ScPz?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}},{"@type":"Comment","text":"The answer is B.\nKinesis Data Streams (real-time stream) enforces a 2 MB/s and 5 transactions/second read limit per shard — and this limit is shared across all consumers reading from that shard using the standard GetRecords API. With three consumers polling the same shard, each consumer’s effective read throughput is throttled to roughly one-third of the shard’s capacity. Each individual consumer is getting around 600 KB/s from a shard producing 1.5 MB/s. That consumer will fall behind.\nThe correct fix is Kinesis enhanced fan-out (dedicated 2 MB/s read pipe per registered consumer — independent of other consumers). When you register a consumer with enhanced fan-out, that consumer gets a dedicated 2 MB/s throughput pipe per shard, independent of every other consumer. The three consumers no longer compete for the same read budget. Enhanced fan-out uses a push model (HTTP/2 streaming) instead of polling — consumers also see lower latency: typically under 70 ms from record ingestion to delivery, compared to 200–400 ms with standard polling.","datePublished":"2026-08-08T17:59:48.319Z","url":"https://daily.dev/posts/bAMC3lvMS#c-5he3x1121","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}},{"@type":"Comment","text":"B is the key here: the limit is shared per shard, not granted separately to each polling consumer. Enhanced fan-out would give the dashboard its own 2 MB/s read pipe, but I’d still watch IteratorAge alongside processing duration so a slow Lambda doesn’t hide behind the same symptom.","datePublished":"2026-08-09T04:20:37.607Z","url":"https://daily.dev/posts/bAMC3lvMS#c-Dx0xtezEC","author":{"@type":"Person","name":"Trevor Suna","url":"https://daily.dev/trevorsuna","image":"https://media.daily.dev/image/upload/s--dZ7gXxpp--/f_auto/v1784081551/avatars/avatar_EMoP47rpuw8DNjhp6R1b6?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"GO ahead brother.","datePublished":"2026-08-09T01:48:12.694Z","url":"https://daily.dev/posts/bAMC3lvMS#c-r7yxyVUce","author":{"@type":"Person","name":"Md. Shafin Ahmed","url":"https://daily.dev/mdshafinahmed","image":"https://media.daily.dev/image/upload/s---a0uwu1i--/f_auto/v1783046504/avatars/avatar_u8iR8DacSYjsphyDqQTQ9?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"Superb @joudawad ! I salute to your consistency!","datePublished":"2026-08-09T05:32:41.393Z","url":"https://daily.dev/posts/bAMC3lvMS#c-IjMEP2N0b","author":{"@type":"Person","name":"Khishamuddin Syed","url":"https://daily.dev/webkmsyed","image":"https://media.daily.dev/image/upload/s--xXLX9Wi9--/f_auto/v1777551874/avatars/avatar_VqsDuiiXz6AnTS1eKLMWz?_a=BAMAMiWQ0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}],"isPartOf":{"@type":"WebPage","url":"https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh","name":"Joud Awad"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Joud Awad","item":"https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh"},{"@type":"ListItem","position":3,"name":"Day 19/30 AWS System Design Patterns"}]} ```