Design a delivery date estimation service
PremiumBackend systemHard
- Promise date
- Order cutoffs
- Transit time percentiles
Quick answer
This backend system interview question asks you to design a delivery date estimation service. Aim for a design that meets its requirements at the stated scale, then explain its main components, data flow and trade-offs. Interviewers want to see how you scope the problem, size it and defend each choice.
The problem
Design a delivery date estimation service for a large online store: it shows "Arrives by Thursday" on search, product and checkout pages. The hard part is turning stock locations, warehouse cutoffs, carrier transit times and holidays into a date that is fast to compute and kept at least 95% of the time.
Every estimate depends on the shopper's postal code, the item and the quantity. An item may be in stock in several fulfilment centres (FCs). Each FC has a daily dispatch cutoff and a daily processing capacity, and each carrier has its own transit times and working days. The date shown at checkout becomes a promise stored with the order.
What must a delivery date estimation service do?
- Estimate on every page: Show an arrival date for each item on search results, product pages and the cart, for the shopper's postal code.
- Promise at checkout: Compute an exact date per shipment at checkout, show it before payment and store it with the order.
How well must it do it?
- Accuracy: At least 95% of orders arrive on or before the promised date, and at most 10% arrive 2 or more days early.
- Latency: Page estimates under 50 ms at p99 for a batch of 24 items; checkout promises under 200 ms at p99.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- Promise date
- Order cutoffs
- Transit time percentiles
- Fulfilment centres
- Business day calendars
- Capacity aware promising
How you’ll practise
- Requirements
- Estimate
- API and data
- High-level design
- Deep dives
- Wrap-up
Lala, personalized to you, gives a hint when you ask and reviews your design when you are ready.
What do interviewers look for?
In any backend system design round.
- Clarifies the requirements before drawing anything
- Uses a few numbers that actually change the design
- Draws a clear path from the client to storage
- Picks storage and caching with reasons, not by habit
- Explains what breaks first under load and how to fix it
- States trade-offs openly instead of claiming a perfect design
Questions people ask about this interview question
- Which design type is this question?
- It is a backend system question. You design a delivery date estimation service and explain your choices the way you would in an interview.
- Is this question asked at entry level?
- It is marked Hard. It suits engineers preparing for senior interviews, where you are expected to drive the discussion and go deep on trade-offs.
- What should I cover first?
- Start with the requirements: what the system must do, how well it must do it and which numbers change the design. Agree on scope with the interviewer before you design anything.
- Can I practise it for free?
- It is a premium question. Sign up and unlock it once for 10 credits; it then stays unlocked. When you finish, Lala, your personalized AI mentor, can review your design for 30 credits.
Related questions
Updated · Written by the SevyDevy team