Design Address Validation

Problem Statement: Why Address Validation Matters

Bad shipping addresses are a silent tax on e-commerce: failed deliveries, carrier surcharges, WISMO ("where is my order") support tickets, and fraud chargebacks when freight-forwarders or synthetic suites slip through. An address-validation platform turns messy human input into a canonical, deliverable, geocoded record that downstream tax, rating, and fulfillment systems can trust — it is the difference between "formatted nicely" and "the carrier will actually deliver here."

A multi-tenant Address Validation Service (AVS) is used at three distinct surfaces, each with a different latency and correctness contract: checkout typeahead (sub-100 ms autocomplete suggestions), the order-commit gate (a hard deliverability check before payment), and the nightly warehouse scrub (bulk revalidation before pick). The core capabilities interviewers expect:

The scale shapes the design: a ~40M-DAU marketplace with a checkout-hour peak drives hundreds of thousands of concurrent checkout sessions, ~16K autocomplete suggest RPS at the edge (mostly absorbed by CDN/edge cache), and ~2.3K validate-at-commit RPS at peak. Google, Smarty, and Melissa sell exactly this (reference data + APIs), and the discriminator in an interview is whether you separate the autocomplete UX from the authoritative verification — autocomplete is a fast, best-effort suggestion; verification is the slow, correct, deliverability-checked gate. The failure to avoid is conflating them: a nicely-formatted address that fails DPV is undeliverable, and treating "looks right" as "is deliverable" is the core mistake. The principle: turn messy input into a canonical, verified, geocoded record; separate fast autocomplete from authoritative verification; and judge the system on deliverability, not formatting.