A small team needs a simple public asset store

Store images and downloadable files, keep access decoupled from the web server itself, and reduce routine infrastructure management.

S3 is the strong category match because the workload is object-based, not disk-based. CloudFront might improve delivery for cacheable content, but that’s a separate delivery decision layered on top.

EBS is a block volume tied to a single compute attachment. EFS is shared file storage designed for multiple instances mounting the same file system. Neither is the natural first choice for a simple object repository.

Before you compare product names, identify the storage interface the scenario actually needs — object, block, or file. That one decision eliminates most of the wrong answers immediately.

Bursting order intake without coupling every component

An order API must stay responsive during traffic bursts. Order processing can happen asynchronously, failures need to be retried, and operators need visibility into what’s happening.

Place a queue between intake and the workers that process orders. Let consumers work at their own pace, record failures, and expose metrics and alarms for operators.

Queue-based buffering gives you consumer control and absorbs bursts naturally. The API can accept and acknowledge work without forcing every downstream dependency to be synchronous.

A pub/sub fan-out mechanism alone isn’t a work queue — it broadcasts, it doesn’t buffer consumer-paced work. A synchronous call chain increases coupling exactly where the requirement says to reduce it. A heavier orchestration layer may add complexity the requirement never asked for if all you need is durable decoupling and retryable work.

“Bursty,” “decouple,” “retry,” and “process independently” are strong signals to evaluate asynchronous buffering — but still check ordering, duplicate handling, visibility, and delivery guarantees before you commit to an answer.

Near-real-time device events with replayable history

A device fleet emits events continuously. The team needs near-real-time processing, a replayable raw history, curated analytics, and controlled access to all of it.

Use a streaming ingestion layer that supports custom consumers, land the raw data in object storage, catalog the schema, transform into curated data, query it, and monitor both job health and quality signals.

Streaming absorbs arrival velocity. Raw storage supports replay if something needs to be reprocessed. A catalog makes schemas discoverable. Transformation produces something actually usable. Analytics answers questions. Monitoring and governance protect the whole lifecycle end to end.

A single database tends to blur serving concerns with historical-lake concerns. A batch-only design would violate the stated near-real-time requirement outright. A catalog by itself provides none of quality, authorization, or lineage — it just makes things findable.

Choose each pipeline component based on the specific data property it needs to handle — arrival, transformation, storage, discovery, quality, access, or observation. Don’t pick a component because it “sounds” like the modern choice.