Amazon·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Apr 2026

Summary

Amazon SWE system design round, one question the whole time. Pretty focused session, they wanted a lot of detail on async flows and storage choices so it wasn't a quick conversation.

Questions Asked (1)

Design a package notification system where customers can subscribe to package status updates and receive asynchronous notifications whenever the status changes. Cover component interactions, the status update flow, and your reasoning for storage choices.

System DesignTechnical Trade-offsData Modeling

Author's notes

I started with the pub/sub layer and worked outward, which felt right in the moment but I probably should've clarified the scale assumptions first.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then propose a high-level architecture with decoupled components (API, message queue, workers, storage). Walk through the status update flow end-to-end, and justify storage choices based on access patterns and consistency needs.

Pro tip: Emphasize idempotency and at-least-once delivery to handle duplicate notifications, and discuss how to scale the system horizontally while maintaining low latency.

1. Clarify Requirements and Scale

Ask about expected number of customers, packages, notification channels (email, SMS, push), and latency requirements. Establish consistency and durability needs.

2. High-Level Architecture

Propose components: API gateway for subscriptions, package status service, message queue (e.g., Kafka/SQS), notification workers, and storage (e.g., DynamoDB for subscriptions, S3 for logs). Explain how they interact.

3. Status Update Flow

Describe how a status change triggers an event: package service publishes to queue, workers consume and send notifications. Include retry and dead-letter queue handling.

4. Storage Choices and Reasoning

Justify using a NoSQL database for subscriptions (high read/write, flexible schema) and a relational DB for package status if strong consistency is needed. Discuss caching for frequent reads.

5. Trade-offs and Scalability

Discuss trade-offs: synchronous vs asynchronous, push vs pull, and how to scale each component. Mention monitoring, metrics, and failure handling.

Key Points to Mention

Decoupling via message queue for asynchronous processing
Idempotency and deduplication to handle duplicate notifications
Storage choices: NoSQL for subscriptions (DynamoDB), relational for package status (Aurora), and caching (ElastiCache)
Scalability: horizontal scaling of workers, partitioning of queue, and auto-scaling
Reliability: retries, dead-letter queues, and monitoring
Notification channels: email, SMS, push, and how to handle preferences

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.