Amazon Work Simulation OA Interview Experience (2026) - OA2 Modules Walkthrough, Offer

This is the part I want to actually talk about. Five modules, each presented as a scenario from a fake Amazon team. Two of them stuck with me.

Module: Real-Time Voting Service for Amazon Voice

Problem: A PM emails asking you to pick a vote storage strategy for a live televised singing show. The constraint block lists per-second vote count updates, millions of concurrent voters over a 5-minute window, availability during the entire window, and the ability for customers to change their vote before the window closes. You rate five storage options from "Not at all Effective" to "Extremely Effective."

The trap is rating document stores or ledger DBs too highly because they sound modern. The right answer is key-value on DynamoDB or Redis. The ranking I went with:

1. Key-value store, extremely effective. Low latency, horizontal scale, native support for per-partition hotkeys.
2. Document store, very effective. Works but the flexibility is wasted here and write throughput is lower than KV.
3. Ledger DB, moderately effective. Auditability is nice for fraud but the append-only constraint makes vote updates a pain.
4. Graph DB, slightly effective. Wrong tool, there are no relationship traversals in this workload.
5. Distributed batch processing, slightly effective. Batch is the opposite of real time.

Customer Obsession shows up here: the customer wants to change their vote before cutoff, which pushes you toward mutable per-key state with quick reads. Anything immutable rates low.

[[problem/142?company=3|Design Rate Limiter]]

Module: Traffic Video Service Message Queue

Problem: Amazon is building a city-scale traffic video service. Cameras push updates into a message queue. You rate options for handling very large payloads (some cameras emit chunks that would overwhelm a standard queue) and separately rate options for making the pipeline resilient to message loss.

My rankings for the large-payload question:

• Fragment large data into multiple messages: extremely effective. Standard pattern, queues hate large blobs.
• Streaming protocol for the camera upload path: extremely effective. Real-time flow control is the right primitive.
• Separate metadata from large payload (two message types): very effective. Classic envelope pattern.
• Cadence-based off-peak sends: moderately effective. Depends on predictable traffic, so brittle.
• Physical download from each location: not at all effective. Obviously absurd for a real-time service.

For resilience, the dominant answer is a dead letter queue plus retry configuration review. I argued the DLQ handles the tail case (messages that will never succeed) while retry policy handles transient faults. TTL and success queues are distractors.

Module: Inventory SaaS Image Storage

Problem: Rate storage options for inventory item thumbnails on a SaaS product. Options include flat file store, relational DB as BLOBs, KV store, Elasticsearch, and a cloud file store like S3.

Cloud file store is the clear winner. This question maps directly to Frugality and Deliver Results: S3 is the boring, correct, low-marginal-cost answer and picking anything else signals you overengineer.

The trap is rating relational DB BLOBs as acceptable. It's technically possible but nobody runs image thumbnails out of Postgres at scale, and the grader knows it.

Modules on System Availability and Project Kickoff

I'll summarize these together because they share a pattern: the most effective actions are the ones that engage the team and the customer, and the least effective are the ones that look productive but avoid decisions. Extremely effective: clarify requirements with stakeholders, ensure elastic capacity, schedule load tests. Slightly effective: increase logging verbosity, set up an architecture review meeting before you understand the system, move configuration into a config service for its own sake.

Ownership is the LP this module leans on. Passive-looking actions tank your rating.

Result

Passed OA2 and moved to VO loop the following week. Where I previously failed, I had rated "schedule an architecture review" as very effective. Looking at the rubric now, that action is premature optimization: you have not even discussed the requirements with the product owner yet.

Tips

1. Treat OA2 as a real exam. A wrong rating on a sim module carries the same weight as failing a test case on the coding OA. Block 50 uninterrupted minutes, do not multitask.
2. Memorize the LP-to-action map. Actions that put the customer first rate "extremely effective." Actions that avoid decisions, add process overhead, or optimize for the wrong phase of the project rate "slightly effective." Actions that are technically wrong (batch for real-time, graph DB for KV workload) rate "not at all effective."
3. Storage picker cheat sheet. KV for low-latency read/write at scale, document for flexible schema at medium scale, object store for blobs, relational for transactional integrity, graph for relationship traversals. Amazon loves DynamoDB and S3 answers.
4. Fragmentation beats cadence for large payloads. Any question about shipping "very large data" in a messaging system, the answer is chunking plus streaming, not batching during off-peak hours.
5. Dead letter queue is a must-mention. Any question about message queue resilience that does not put DLQ first is wrong. Pair it with retry config review for the perfect score.
6. Do not rate two contradictory actions both extremely effective. If the scenario says "you are in early architecture," rating "set up an ops dashboard" and "clarify requirements with PM" both as extremely effective is a tell that you did not read the phase carefully. Prioritize by project stage.