Design A Low-Latency Product Price Update API
Company: Microsoft
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
Design an API and serving system for product prices. Each product price is updated at most once every 24 hours, but the product launch page needs low-latency reads for all products at high traffic.
<details>
<summary>Hint 1</summary>
Start by naming the core entities, constraints, and success criteria.
</details>
<details>
<summary>Hint 2</summary>
Make the trade-offs explicit before going deep on implementation details.
</details>
### Constraints & Assumptions
- Reads are much more frequent than writes.
- Each product has at most one price update per day.
- The launch page may request many products at once.
- The system should prioritize low read latency and consistent published prices.
### Clarifying Questions to Ask
- How many products are displayed on the launch page?
- Are price updates scheduled or manual?
- Does the page require strong consistency immediately after an update?
- Can prices be precomputed into a page-specific payload?
- What are the traffic and latency targets?
### What a Strong Answer Covers
```premium-lock What a Strong Answer Covers
```
### Follow-up Questions
- How would you support flash-sale overrides?
- How would you roll back a bad price update?
- What cache key would you use for the launch page?
- How would the design change for per-user prices?
Quick Answer: Prepare for a read-heavy product pricing system design interview where prices update infrequently but launch-page reads must be low latency. The prompt focuses on versioned price records, caching, bulk reads, invalidation, rollback, and consistency after daily updates.