During a holiday parade, citizen phone apps will spike location and crowd-density telemetry far above normal weekday rates. What should architects do when planning Amazon Kinesis Data Streams and Amazon Data Firehose capacity for that day?
Select an answer to reveal the explanation.
Short Explanation
Parade day is rush hour for telemetry—size the lanes before the floats roll. Provision Kinesis shards and respect Firehose limits for the peak, not the quiet Tuesday baseline. Defaults forever, turning off encryption, or a lone tiny EC2 broker won’t carry the crowd.
Full Explanation
Parade-day citizen apps will drive location and crowd-density telemetry far above weekday baselines, so architects must plan Amazon Kinesis Data Streams shard capacity (or on-demand mode) and Amazon Data Firehose throughput limits for that peak rather than for a quiet Tuesday. Provisioning for the holiday ingest spike prevents throttling, elevated iterator age, and delayed municipal safety dashboards when attendance surges. Ignoring peak rates and relying solely on default single-shard settings forever is a classic under-provisioning failure under bursty events. Disabling encryption during the parade does not multiply throughput and would weaken security for citizen location data when risk is highest. Moving the stream to a single t2.micro EC2 broker managed by hand replaces managed streaming with a fragile bottleneck that will not absorb parade-scale fan-in. Exam caveat: know how Kinesis throughput relates to shards/on-demand, and that Firehose has delivery and buffering limits you must design around; scaling after the parade starts may be too late for real-time crowd safety uses. Operational check: estimate peak records/bytes per second from prior events, load-test producers against the planned shard/Firehose configuration, set alarms on throttling and iterator age, and document a scale-up/scale-down runbook for the event window.