Design a Product Inventory and Pricing Service
Company: Moodys
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
## Design a Product Inventory and Pricing Service
Design a read-heavy service for an e-commerce platform. It must return product details, allow authorized price updates, and decrement inventory when a customer places an order. Discuss consistency versus availability for each operation and prevent overselling when many customers purchase the same item concurrently.
Your design should compare SQL and NoSQL storage, REST and gRPC interfaces, a Redis cache, Bloom filters for invalid product lookups, and a primary-replica database topology. Address cache invalidation, authorization, database and cache failures, hot products, and operational observability.
### Constraints & Assumptions
- Product-detail reads greatly outnumber price and inventory writes.
- Inventory correctness is more important than serving an immediately successful checkout.
- Prices and product descriptions may tolerate bounded cache staleness, but checkout must use an authoritative price and inventory decision.
- Clients may retry timed-out requests.
### Clarifying Questions to Ask
- Is inventory tracked as available units, reservations, or both?
- Can orders span products stored in different inventory partitions?
- What price must checkout honor if a cached display price changes before purchase?
- Which roles may update price, and is dual approval required for sensitive changes?
```hint Separate browse from commit
Optimize product browsing independently, but put price validation and conditional inventory mutation behind an authoritative transaction boundary.
```
### What a Strong Answer Covers
- Clear APIs and data ownership for product, price, inventory, reservation, and order records.
- An ACID or conditional-write path that makes inventory decrement atomic and idempotent.
- Cache-aside reads with versioned invalidation, stampede protection, and a safe fallback during Redis failure.
- Careful use of replicas and Bloom filters without treating either as authoritative at checkout.
- Hot-key handling, request coalescing, authorization, audit logs, metrics, and reconciliation.
### Follow-up Questions
- What happens when the entire Redis cluster is unavailable?
- How would you reduce duplicate database reads when thousands of users request one product simultaneously?
- Why can a Redis atomic decrement still be unsafe as the only inventory record?
Quick Answer: Design a read-heavy product, price, and inventory service that remains fast for browsing without weakening checkout correctness. The exercise compares storage and interface choices while probing conditional inventory updates, authoritative pricing, retries, caching, hot products, authorization, and failure recovery.