The interviewer asked me to design Amazon order tracking

The tweet is a postmortem-style interview lesson: the author admitted overengineering a design by diving into Kafka before defining core requirements and users. It emphasizes starting with requirements—who consumes tracking data (customer, seller, support, carrier ops)—and designing for clear read paths over write paths. They outline practical architecture: order/shipments/tracking events model, API surfaces for current status and event timelines, idempotent carrier ingest, and a projection-based read model for fast status retrieval. They also stress correctness constraints like non-regressive statuses, event ordering per shipment, dedupe/idempotency, GDPR-like deletion concerns, and observability/failure scenarios.

Relevance

Highly relevant to your platform and architecture interests (Norviq, HermesVault) because it prioritizes robust distributed system boundaries: event log + projector pattern, read model consistency tradeoffs, and operational hardening for eventual consistency under load.

Notes

• Canonical source URL normalized (removed tracking query).
• Metrics were incomplete on mirror fallback; only views were confirmed (973).