AWS Service Primitives And Amazon Design Tradeoffs

What's being tested

Interviewers probe your ability to map application requirements (throughput, latency, durability, ordering, cost, operational burden) to AWS building blocks and explain concrete tradeoffs. They expect clear choices among primitives like messaging, streaming, object storage, key-value stores, and serverless compute, plus patterns (idempotency, backpressure, batching) that make systems correct and resilient. Amazon cares because engineers must deliver scalable, cost-effective services that operate at high availability inside AWS constraints.

Core knowledge

AWS primitives taxonomy — know the roles of `S3` (durable object store), `DynamoDB` (managed key-value with single-digit-ms reads), `RDS/Aurora` (relational OLTP with ACID), `SQS`/`SNS` (queue/topic), `Kinesis` (streaming with ordered shards), `Lambda` (serverless compute), `EC2/ECS/EKS` (container/VM compute).
Delivery & ordering guarantees — `SQS` standard: at-least-once, best-effort ordering; `SQS` FIFO: message-group ordering and deduplication window (not strict global ordering); `Kinesis` gives per-shard ordering and at-least-once delivery.
Consistency vs availability tradeoff — strong consistency (e.g., `RDS` transactions, `DynamoDB` strongly-consistent reads in-region) vs eventual (cross-region replication, `S3` object replace/delete semantics); pick based on correctness needs and latency budget.
Throughput primitives and scaling math — streaming throughput = shards * per-shard capacity (`Kinesis`: writes ≈ 1 MB/s or 1000 records/s per shard; reads ≈ 2 MB/s). For batch-oriented queues, throughput often limited by consumer concurrency.
Storage semantics and durability — `S3`: highly durable (~11 nines) object storage suitable for large immutable blobs and long-term logs; `EBS` for block-level, `EFS` for shared file access. Use `S3` for cheap durable log/backup.
Idempotency and uniqueness — design producers/consumers for idempotency using stable idempotency keys, dedup tables in `DynamoDB`, or use `SQS` FIFO deduplication when appropriate; critical when primitives deliver at-least-once.
Transactional patterns — for cross-service consistency prefer outbox pattern (write-to-db + publish event) or use database transactions where possible; avoid distributed transactions across AWS services unless you accept complexity.
Retry/backoff and error handling — use exponential backoff with jitter for retries; configure dead-letter queues (`DLQ`) for `SQS` and `Lambda` to surface poison messages; implement circuit-breakers for downstream overload.
Cost & operational tradeoffs — serverless (`Lambda`, `SQS`) reduces ops but can increase per-request cost and cold-start latency; provisioned services (`EC2`, `ECS`, `RDS`) give cost predictability and control for sustained high throughput.
Networking, latency, and data transfer cost — cross-AZ traffic generally free for most services but cross-region egress has measurable cost and higher latency; collocate producers and consumers in same region/AZ where latency and egress matter.
Observability primitives — instrument p50, p95, p99 latency, error rates, throughput; use `CloudWatch` metrics, `X-Ray` traces for request graphs, and `CloudTrail` for control-plane audit.
Security and operational constraints — use `IAM` least-privilege, `KMS` for encryption at rest, and VPC endpoints for private service access; design for key rotation and least-exposed network surfaces.

Worked example — "Design a scalable pub/sub notification service using AWS primitives"

First 30s framing questions: clarify throughput (messages/sec and size), ordering needs, exactly-once vs at-least-once requirements, multi-region delivery, and latency SLOs. Skeleton of a strong answer: (1) pick a publish mechanism (`SNS` for fanout) and durable delivery targets (`SQS` queues per subscriber or `Lambda` for direct processing); (2) design for scale and failure (each subscriber uses an `SQS` queue with `DLQ` and visibility timeout tuned to processing time); (3) ensure correctness (idempotency keys and optional `FIFO` queues when ordering matters); (4) monitoring and cost controls (`CloudWatch` alarms, delivery metrics, `DLQ` alerts). Explicit tradeoff: using `SNS`→`SQS` scales fanout with decoupling and durability but yields at-least-once delivery — if subscribers require strict exactly-once or global ordering, you'd need `SQS` FIFO or end-to-end deduplication at consumers, increasing latency and reducing throughput. Close: "If I had more time I'd prototype high-load scenarios, tune VisibilityTimeout and batch sizes, add per-queue concurrency autoscaling, and model cost at expected QPS."

A second angle — "Design an order ingestion pipeline with exactly-once semantics across microservices"

Same AWS primitives behave differently: here ordering and exactly-once matter per order ID. Candidate options: use `SQS` FIFO to preserve order and eliminate duplicates within the deduplication window, or use the outbox pattern in the order service (write order and journal event in one DB transaction, then publish to `Kinesis` for downstream consumers). Key decisions: prefer transactional outbox plus at-least-once consumer with idempotent handlers if you want strong durability without distributed transactions; prefer `Kinesis` when you need ordered replay and stream retention for reprocessing. Also consider `DynamoDB` streams + `Lambda` for scalable change-data-capture, but remember cross-region replication is eventual — account for potential reordering at global scale.

Common pitfalls

Pitfall: Choosing `SQS` standard because it's "faster" without addressing deduplication — leads to duplicate processing bugs in stateful consumers. Always design for idempotency or use FIFO when ordering/dedup is required.

Pitfall: Treating `Lambda` concurrency as unlimited — failing to provision reserved concurrency or control downstream resources (`DynamoDB`/`RDS`) causes throttling spikes and cascading failures; model concurrency vs downstream provisioned capacity.

Pitfall: Ignoring monitoring and `DLQs` — assuming success if no visible errors; configure `DLQs`, per-queue metrics, trace sampling, and automated alerts to detect poison messages and backlog growth early.

Connections

Interviewers may pivot to capacity planning and cost optimization (provisioned vs on-demand capacity decisions), or to data modeling for `DynamoDB` (partition keys, GSIs, hot partitions). They may also explore observability (tracing cross-service flows with `X-Ray`) or security (`IAM` roles and `KMS` encryption) depending on weakness in your tradeoff rationale.