Design a Package Tracking Widget for an Email Inbox

Design a package tracking widget for a Gmail-like consumer email product. When a shipping or order email arrives, the system extracts the carrier tracking numbers it contains. A widget in the user's inbox lists that user's active shipments with the current status of each, and the system keeps those statuses fresh as the packages move. The feature may add only a small amount of latency to the email ingestion path and to the inbox read path. ```hint Map the two hot paths Write down every step between an email arriving and it appearing in the inbox, and between the user opening the inbox and the page rendering. For each piece of tracking work, decide whether it truly has to sit on one of those paths. ``` ```hint More than a pattern match A string shaped like a tracking number is often an order number, a phone number or a coupon code. Think about which other signals in the email can raise or lower your confidence. ``` ```hint Freshness has a price Every active shipment needs updates from a carrier, and carriers limit how often you may ask. Consider which shipments need frequent updates, which hardly need any, and whether a carrier can tell you about a change instead of being asked. ``` ### Constraints and Clarifications - Assume carriers expose tracking APIs that return a package's status and scan history, with rate limits that differ by carrier; some carriers can also push updates. - The mail delivery pipeline and the inbox already exist. You are adding this feature to them, not redesigning them. - A shipment is identified by its carrier and tracking number. Several emails, and several users, can refer to the same shipment. ### Clarifying Questions - How many users and incoming emails per day, and roughly what share of emails mention a shipment? - What does "a small amount of latency" mean in numbers, for mail delivery and for inbox load? - How fresh must a status be? Should a package that is out for delivery be updated more often than one in transit? - When does a shipment stop being active: on delivery, some days after delivery, or when the user dismisses it? - Which carriers must be supported at launch, and do any of them push updates? - Should order confirmations that contain no tracking number appear in the widget too? - What privacy rules apply: per-user opt-out, enterprise accounts, and what happens to a shipment when the user deletes the email it came from? ### What a Strong Answer Covers - An explicit latency budget for the ingestion and inbox read paths, and which work is moved off each of them - An extraction pipeline that is accurate (candidate detection, validation, context signals) and whose quality can be measured - A data model that separates each user's link to a shipment from the shared per-package status, with deduplication of repeated emails - A freshness strategy that respects carrier limits: push where available, prioritized polling elsewhere, and a point at which tracking stops - A read path that serves precomputed per-user data and degrades to "no widget" instead of slowing the inbox - Lifecycle, privacy and deletion handling, plus failure modes such as a carrier outage or an extraction backlog - Staff-level scope: a phased rollout, metrics for extraction quality and staleness, and clean contracts with the teams that own delivery and the inbox ### Follow-up Questions - A major carrier's tracking API is down for several hours. What do users see, and how do you recover without flooding the carrier when it returns? - Peak shopping season multiplies the volume of shipping email several times over. Which part of the design is stressed first? - How would you measure extraction precision and recall without people reading users' email? - How would you notify a user when a package is out for delivery, without notifying twice when two emails refer to the same package?