I built a 3D game that shows the exact hop where your AWS design fails. Help me break it.

Vivek Padia — Wed, 21 Oct 2026 10:07:17 +0000

Every AWS practice exam I took had the same ending: "Incorrect."

Sometimes there was an explanation. Usually it was a paragraph that told me what the right answer was, not why my design would actually fail. I'd memorise it, pass the question next time, and still not really understand route tables, security groups or NACLs.

So I built the thing I wanted while studying: Tracesleuth, a 3D browser game where you learn AWS by watching your own designs fail.

A packet dropped at the exact hop, with the reason

How it works

Each stage is an exam-style scenario: "Customers can't load the storefront", "The database must only be reachable from the web tier", "This pipeline costs too much".

Build the design in 3D. The Region is the ground, Availability Zones are islands, the VPC is a glass enclosure, and subnets turn green when they become public.
Press Send traffic. Packets travel hop by hop through your design.
Watch it fail, precisely. When a packet is dropped, it stops at the exact hop that dropped it: "main-rtb has no route to 203.0.113.25". Then you get why it failed, the concept behind it, and an exam tip.
Fix it and send again. Hints get more specific step by step, and a model solution unlocks once you've used them.

The AI, data and architecture worlds use a "solution board" instead of packets. Each requirement is a row, you drop the AWS service that serves it into the slot, and a sample request runs along the row until the service that can't handle it rejects it, with the error the API would return.

What's in the beta

Six domains: networking, security, core architecture, data engineering, AI and machine learning, and operations.
Mapped to the exams: SAA-C03, SAP-C02, SOA-C03, DVA-C02, DOP-C02, SCS-C03, DEA-C01, ANS-C01, AIF-C01, MLA-C02 and AIP-C01. Pick an exam and the map shows only the stages its guide covers.
Free, with no sign-up: the first stage of every domain.
Desktop browsers only for now.

👉 Play it: beta.tracesleuth.com

A few decisions that might interest you

No AI grading. A deterministic, unit-tested simulator decides pass or fail. The same design always gets the same verdict, and every failure maps to a hand-written explanation. I didn't want a learning tool that sometimes hallucinates why your security group is wrong.
No AWS account and no bill. Everything is simulated in the browser, so you can break a NAT gateway as often as you like.
Every check passes or fails for a stated reason. The explanation quotes your own design: which route table, which rule, which CIDR.
Privacy. Analytics are cookieless and count stage starts and clears, never anything you type.

What I need from you

I'm a small team, and right now I can't tell whether this is genuinely useful or just pretty. Honest, even harsh, feedback is the most valuable thing you can give me. Try one stage (about 10 to 15 minutes) and tell me:

Did the failure explanation make it click? Or did you still not get why?
Was the scenario realistic, compared with the exam or with real work?
What was confusing, clunky or broken? Screenshots are gold.
Would you use this alongside practice exams? If not, what's missing?
Which certification should get the most stages first?

You can reply in the comments, or use the Feedback button in the game. If you'd like to test the full game, join the waitlist on the site. I'll send invite codes to people who leave detailed feedback.

Thanks for reading, and good luck to everyone with an exam coming up. 🙏

Your best-selling SKU was out of stock for 13 hours and nobody noticed: real-time availability monitoring for D2C brands

Vivek Padia — Thu, 06 Aug 2026 11:10:32 +0000

The Friday night nobody noticed

It is 11 PM on a Friday. A dark store in one city runs out of your best-selling SKU. The listing does not throw an error or send anyone an email; it just greys out. Your performance ads keep serving, the campaign keeps spending, and every system involved behaves exactly as designed.

Saturday, 12:10 PM: a customer DM lands on Instagram asking why they cannot order. Ops opens the app, finds the grey button, calls the distributor, and stock is back by early afternoon. Thirteen hours before anyone even knew, one SKU, one city.

That evening slot normally moves about 8 units an hour at Rs. 450 a unit. 8 units x 13 hours x Rs. 450 is Rs. 46,800. Call it Rs. 47,000, gone silently, on one SKU in one city over one night.

Nobody made a mistake. The warehouse did its job, the platform did its job, the ads did their job. There was simply nothing watching.

What a stockout actually costs

Rs. 47,000 is only the visible layer. A stockout charges you four times, and only the first charge shows up anywhere you currently look.

Direct lost sales. The base formula is hourly sales velocity x stockout hours x unit price, per SKU, per platform, per city. The load-bearing word is hourly. A hero SKU that sells 8 units an hour at 9 PM might sell 1 unit an hour at 4 AM, so pricing a stockout with a flat daily average understates the evening outage and overstates the overnight one. It also decides urgency: an alert that says "SKU-1042 out of stock" is easy to defer, while "SKU-1042 out of stock, Rs. 3,600 per hour at risk" is not.

Priced honestly hour by hour, Friday night's Rs. 47,000 comes in lower, and an outage from 6 to 9 PM comes in higher, which is exactly why a flat number cannot be trusted in either direction. Hold onto that hourly figure: it is the exact number the monitoring system needs, per SKU and per hour of day, to price an open stockout while it is still open.

Wasted ad spend. Campaigns do not pause themselves when a listing stops being buyable. Clicks keep landing on a grey button and you keep paying for them, and if your top three SKUs carry most of your ad budget, a weekend stockout on one of them burns real money for nothing. You are paying to advertise something nobody can buy. The fix is not someone pausing campaigns by hand at midnight; it is knowing the listing is dead within minutes, which makes this a monitoring problem before it is a marketing one.

Ranking decay. This is the second-order cost, and it outlasts the stockout. Availability feeds every platform's ranking model, so a listing that goes dark overnight gets demoted, and restocking does not restore rank. Recovery takes days of renewed sales. A 13-hour stockout is not a 13-hour problem; it is closer to a week of depressed velocity on your best listing.

Substitution and lifetime value. On quick commerce, switching costs the customer one thumb-tap. Some of the buyers who hit the grey button buy a competitor instead, and a fraction of those do not come back. You lose not just tonight's order but a slice of every order that customer would have placed after it.

The composite model:

monthly stockout cost =
    direct     sum per incident: velocity[hour of day] x price x hours out
  + ad waste   spend rate on the affected listings x hours out
  + decay      velocity shortfall after restock x recovery days x price
  + churn      blocked buyers x switch rate x never-return rate x future margin

Worked through for a hypothetical brand doing Rs. 2 Cr a month in GMV across 40 SKUs, 3 platforms and 6 cities, with assumptions stated per row:

Component	Working assumption	Monthly cost
Direct lost sales	~25 incidents x 9 hrs average x ~Rs. 800/hr at-risk velocity	Rs. 1.8 lakh
Wasted ad spend	Rs. 20 lakh monthly spend, 2-3% served against unbuyable listings	Rs. 0.4-0.6 lakh
Ranking decay	3-4 days of ~30% depressed velocity after each incident	Rs. 1.5-3.5 lakh
Substitution and churn	~20% of blocked buyers switch, a third of those stay gone	Rs. 0.4-1.5 lakh
Total		~Rs. 4-7.5 lakh

The at-risk velocity in that first row is roughly 20x the average listing-hour. Rs. 2 Cr a month spread over 720 listing states is about Rs. 38 per listing-hour, and the gap is deliberate, because stockouts concentrate on hero SKUs at peak hours. A stockout is what happens when velocity outruns replenishment.

Run the model and a brand doing Rs. 2 Cr a month is carrying Rs. 4-7.5 lakh of stockout cost, roughly 2 to 4 percent of GMV once lost sales, wasted spend and forgone future margin are added up. Your numbers will differ; the components will not. And none of this appears on any report as a line called "stockout cost". It is smeared across sales, marketing and retention metrics, which is exactly how it survives quarter after quarter.

Why a person checking apps cannot fix this

The instinctive fix is a WhatsApp group and a checking rota, and it fails on arithmetic before it fails on discipline. The brand above has 40 SKUs x 3 platforms x 6 cities: 720 listing states, each able to flip any hour. Checking each twice a day is 1,440 checks and still leaves 12-hour blind windows, and the Friday-night stockout burned straight through one of them.

Seller dashboards do not close the gap either. They lag by hours, they are one-platform silos with no combined view, and most report what you shipped to the warehouse rather than what a buyer in a given pincode actually sees. A listing can be in stock in the panel and unbuyable on the app at the same moment: suppressed from search, buy box lost, pincode unserviceable. If your check reads the panel, that failure is invisible by construction.

And even a perfectly executed rota records nothing. There is no history, no answer to how many hours the hero SKU was dark last month, no rupee attribution, no way to tell whether this quarter is better or worse than the last one. A recurring operational loss with no KPI attached to it never gets budget, so it never gets fixed.

That failure yields three requirements: detection in minutes, on the system's schedule rather than a person's; every alert priced in rupees at risk, so the expensive stockout outranks the trivial one automatically; and stockout history stored as a first-class business KPI you can trend. The rest of this post is the architecture those three requirements force.

The architecture

Read it left to right: sources, one normalizing ingest layer, an event backbone, detection that prices what it detects, then alerts and a dashboard, with Airflow keeping the fast loop honest. Every AWS service named is the boring managed option: MSK, ECS Fargate, RDS, SQS, SES. The interesting decisions are in the flow.

Connectors. Every platform exposes inventory truth differently, so the system speaks three connector shapes: a marketplace seller API, a storefront API with webhooks, and warehouse CSV drops on S3. The marketplace connector is the one worth studying, because it carries the awkward parts of real seller APIs like Amazon's SP-API.

Tokens expire, so a token manager refreshes proactively at 90 percent of lifetime, single-flight, so concurrent requests do not stampede the auth endpoint. Rate limits belong to the server, so the client reads the rate-limit header on every response and retunes its token bucket instead of hardcoding published numbers. And it runs two channels at once: webhook notifications for speed, polling for truth, because notifications get dropped in transit and a missed "went out of stock" is precisely the failure this system exists to catch.

Two scope notes, because honesty is cheaper than being caught. In the repo the marketplace connector runs against a simulator implementing the same contract: token endpoint, rate-limit headers, injected 429s, added latency, dropped push notifications. That last fault is what argues for polling, and the connector stays production-shaped without a live seller account.

The connector shape the repo does not ship is the buyer-side poller for quick-commerce apps with no seller API, the platform type in the opening scene. That is respectful-scraping territory, with its own rate, serviceability and anti-bot constraints, and deserves its own writeup. Its production shape is pincode-sampled storefront checks emitting the same normalized reading, so nothing downstream changes.

Whatever the source, everything normalizes into one reading: SKU, location, channel, available, on hand, reserved, buyable, observed-at, source. Downstream code is platform-agnostic by construction. Buyable is deliberately separate from available, because seller-reported stock and buyer-visible availability are different facts, and a listing with units on hand that will not sell (suppressed, buy box lost, unserviceable) trips its own rule no stock count could see.

The event backbone. Readings become events on Kafka topics keyed by SKU, published through a transactional outbox: the state change and the outgoing event commit in one database transaction, and a relay publishes pending rows, so a crash causes a re-publish, never a lost event. Four independent consumer groups hang off the backbone: rules evaluation and an event ledger on the stock-changed topic, sales-velocity aggregation on orders, and the notification bridge on alert lifecycle events.

Do you even need Kafka? At small scale, no. Fifty SKUs on 2 platforms polled every 5 minutes is under 30,000 events a day, and a cron writing to Postgres absorbs that without noticing. Even 500 SKUs across 5 platforms at 10-minute checks is about 360,000 events a day, around 4 per second.

Event volume never justifies Kafka at this scale. Consumers, replay and burst shape do. Past 2 or 3 independent consumers of the same stream, or the first time you need to replay history after a bug, a work queue starts fighting the problem, and a flash sale arrives as a spike that the daily average hides. This repo clears it on replay rather than consumer count, with only two groups on the stock-changed stream. Below that line, SQS or a polled Postgres table is simpler, and simpler is a feature.

Detection that knows what money looks like. The rules evaluator alerts on transitions, not levels. "Went from in stock to out of stock" fires once; "is currently out of stock" would re-announce the same incident every sweep, dozens of times a day. Hysteresis handles the boundary: a low-stock alert resolves only after stock climbs back above threshold plus a margin, so a SKU oscillating around the line does not flap the channel. Each alert is enriched at fire time with hour-of-day velocity: a trailing 14-day mean per hour bucket, times unit price. The rupees-per-hour figure rides inside the payload.

Measured locally against the docker compose stack, the full path lands in 4 to 5 seconds: storefront webhook to ingestion to outbox to Kafka to rules to a triggered alert.

Airflow, the slow loop. Streaming answers what changed in the last minute; Airflow answers whether our picture of the world is still correct. A nightly DAG drives every connector through a cursor-free full snapshot, diffs it against the live model, and emits corrections back through the normal ingestion path, so every consumer sees them as ordinary facts. An hourly DAG refreshes the velocity model; a manual DAG replays topic windows for backfills. The nightly diff catches what a stream of increments cannot: the dropped webhook, the source that fell behind.

Serving. No dashboard read walks the order stream: sales velocity is pre-aggregated into an hour-bucket table the stream maintains, and every rupee figure is integrated over those buckets. History is the honest exception: the availability views scan the append-only snapshot series at request time within a 30-day lookback, and event feeds read the ledger directly.

Those derived read models can be rebuilt by clearing the consumer's dedupe rows and replaying Kafka. They are cache-shaped state, not a second source of truth; the canonical inventory model is written by the ingestion path that publishes the events. The heatmap ranks rows by rupees at risk, and the alert inbox lists open alerts first by severity, then by rupees at risk, so the SKU actually bleeding money is never buried under slow-movers.

Both captures below are from the seeded demo mid-flash-sale, which lifts that hour's velocity bucket; at rest these SKUs read Rs. 3,000 to 9,000 an hour.

How this usually gets built wrong

The same five patterns appear in most home-built availability monitors. Each one looks reasonable on day one.

The one-table poller. Poll everything into a single readings table and aggregate at read time. Week one it is fine; at a few million rows the dashboard is scanning history on every page load, queries time out, and someone bolts on a cache that hides the problem until it is worse. Pre-aggregating at write time is the fix, and it usually arrives as a crisis rebuild instead of a design decision. You can spot the shape of it from outside: a dashboard that was fast in the demo and unusable by month three.

Alerting on checks instead of transitions. Every 10-minute sweep re-announces everything currently out of stock. That is 40 messages before breakfast, all of them repeats. Humans respond by muting the channel, and from that moment the monitoring is dead while running perfectly. Nobody announces the mute; you discover it during the next stockout. Alert volume should be proportional to state changes, which are rare, not to checks, which are constant.

Polling without manners. No backoff, no jitter, a fixed IP and an aggressive interval. It works for two weeks, then the platform rate-bans the scraper and monitoring goes dark, and "no alerts" quietly starts meaning "no coverage" instead of "no problems". Being a polite client (adaptive rates, exponential backoff, jittered retries) is not etiquette; it is what keeps the data flowing.

Treating every SKU the same. The hero SKU's stockout arrives as alert 7 of 23, below six slow-movers nobody will restock this quarter. Ranked by rupees at risk it would be alert 1. Severity should come from money, not from rule type, and that ranking needs the velocity model, which is why pricing and alerting have to be one system.

Pricing loss from daily averages. A flat daily-average velocity understates peak-hour stockouts at exactly the moment they matter most, by your peak-to-average ratio: the 8-units-at-9-PM against 1-unit-at-4-AM profile from earlier averages out well below its own peak. The 9 PM outage gets priced like the 4 AM one, and the alert that most needed urgency reads as routine.

Production concerns and the AWS bill

Rate limits shape the design, not throughput. At this event volume, compute is never the constraint; the platform's request budget is. Batching SKUs per request, adapting the client's token bucket to what the server currently allows, and backing off with jitter on 429s decide your real detection interval. The connector treats the platform's budget as the platform's property and adjusts to it at runtime.

At-least-once, made safe. The outbox relay guarantees delivery by allowing re-publishes, so every consumer is idempotent: processed event ids are recorded and a replayed event is a no-op. Notification delivery dedupes the same way, so a retried delivery is a no-op once the send is recorded. The exactly-once machinery Kafka offers is deliberately not used here: the idempotency discipline is simpler to reason about and, more importantly, simpler to test.

Monitoring the monitor. A dead poller and a fully stocked catalog both produce no events at all. Left alone, "everything is in stock" and "the monitor has been down since Tuesday" are indistinguishable, so connector health is a monitored fact. Consecutive sync failures escalate a connector's status and fire an alert of its own, which covers the loud failure. The nightly reconciliation covers the quiet one: a location whose last observation has gone stale while other locations keep reporting gets flagged, catching the poller that stopped without ever raising an error.

The bill. Dev-sized on AWS in us-east-1, from the CloudFormation templates in the repo. One scope note: Airflow runs local-only in this repo, so the slow loop is not in this bill; budget MWAA or self-hosting separately if you want it in the cloud.

Resource	Monthly estimate
MSK, 2 x kafka.t3.small	~$71
NAT gateways, one per AZ	~$66
Fargate, 5 services	~$48
ALB	~$20
RDS db.t4g.micro	~$14
CloudWatch, SQS, S3, misc	~$5
Total	~$224/month

MSK dominates, and it is the honest price of managed Kafka: below the consumer-count threshold from earlier, replace it with SQS or Postgres and cut the bill by a third. The NAT line is a choice, not a given: two gateways buy availability-zone redundancy, one saves $33 a month, and for a dev environment one is the right trade. For evaluation, docker compose on a laptop is free.

At 10x the volume the first change would be the snapshot history table: range-partition it by month, or move cold history to S3 with Athena over it, because the append-only time series outgrows everything else first. The second would be sizing Kafka partition counts up front, since repartitioning a live SKU-keyed topic is the kind of migration you plan around. Everything else scales on knobs the design already has: consumers by partition, workers by queue depth, API by CPU.

Three lessons and a repo

Alert on transitions, not states: the information is in the moment something changes, and everything else is repetition that trains people to stop reading. A rupee figure in the alert gets triaged where a severity label gets muted. And reconcile what you stream, because incremental readings drift, and a nightly full-snapshot diff is cheap insurance against the misses you cannot see from inside the stream.

Everything above is running code: github.com/vivekpadia70/stockwatch. Bring it up with docker compose, seed the demo catalog, trigger the flash-sale scenario, and watch a priced alert fire and auto-resolve. More than 500 tests, the CloudFormation stacks and the cost breakdown are in the repo.

I take on select data engineering engagements - reach out on LinkedIn.

DEV Community: Vivek Padia