Food Delivery System — system design by AgileViper46

Availability is not called out as an explicit quality target

You mention latency, consistency, and scale, but what happens when Elasticsearch, Redis, Google Maps, or Kafka is degraded? Without an explicit availability objective or degraded-mode expectation, it is hard to judge whether the system should fail closed, serve stale results, or partially operate during dependency outages.

Scalability numbers are incomplete for the hottest path

You state 5K concurrent orders and roughly 25K reads, but have you considered what that means for the transactional inventory reservation path specifically? Strong consistency is fine, but the design should connect the concurrency assumption to expected contention on popular SKUs or distribution centers; otherwise the write path may meet correctness but miss throughput under bursty demand.

Order-to-product relationship is not modeled explicitly

Have you considered what happens when one order contains multiple items? The requirements explicitly require multi-item orders, but the entities stop at Order and Product without introducing an OrderItem or line-item relationship. Without that join entity, the many-to-many relationship between orders and products is left implicit, and it becomes unclear how quantities, per-item fulfillment, and order history are represented.

Inventory relationships are underspecified

Have you considered how Inventory connects to both Product and Distribution Center? Availability by location depends on inventory being scoped to a specific product at a specific DC, but that relationship is not stated explicitly. If Inventory is not clearly modeled as the intersection of Product and Distribution Center, the happy path for 'what items are available from which nearby DCs' becomes ambiguous.

Write QPS is derived from concurrency, not arrival rate

Have you considered what happens if 5K concurrent orders does not mean 5K write QPS? Concurrency and QPS are different dimensions: 5K in-flight orders could correspond to far lower or higher request throughput depending on latency. If the write baseline is off, every downstream estimate for database capacity, Kafka throughput, and Elasticsearch update volume will also be off. You could improve this by converting 100K orders/day into average and peak order creation QPS, then using the 5K concurrent figure to reason about connection pools and in-flight work separately.

Peak traffic and burst assumptions are missing

Have you considered what happens during lunch/dinner spikes or regional bursts? 100K orders/day averages to a low steady-state rate, but this kind of system is usually highly bursty. Without a peak multiplier or busy-hour estimate, it is hard to tell whether PostgreSQL, Redis, Elasticsearch, and Kafka are sized for real production load or just daily averages. You could improve this by stating a peak-hour fraction or a simple burst factor and sizing hot-path components against that.

No end-to-end capacity chain from traffic to storage and bandwidth

Have you considered what happens when order history, inventory CDC, and search indexing grow over time? The section gives only read/write QPS, but for a senior-level capacity discussion I would expect at least rough storage growth for orders, order items, inventory holds, Kafka retention, Elasticsearch index size, and Redis cache footprint. Without that chain, it is difficult to judge whether the chosen infrastructure still fits after months of growth. You could improve this by adding back-of-envelope estimates for data per order, retention period, replication overhead, and CDC/event volume.

Read QPS is not tied to the actual access patterns in the design

Have you considered what happens when search traffic dominates order traffic? The design includes product availability search, geospatial DC lookup, travel-time cache lookups, order placement, and order history reads, but the single 5:1 read/write ratio does not explain how much load lands on Elasticsearch versus Redis versus PostgreSQL. If search is much hotter than ordering, Elasticsearch and Redis may be the real bottlenecks even if order writes are modest. You could improve this by breaking read traffic into major flows and mapping each to the serving system.

Search and availability contract is split awkwardly across two APIs

Have you considered what the client experience looks like when it has to call `GET /products?...` and then separately call `GET /inventories/{product_id}?shops=...` for each product? For a search page with many results, this turns into an N+1 API pattern and makes it unclear which endpoint is the source of truth for 'deliverable within 1 hour'. You could improve this by returning deliverable availability in the search response itself, or by offering a batch availability endpoint for multiple product IDs.

List orders endpoint has no pagination or filtering story

What happens when a long-time customer has hundreds or thousands of past orders and calls `GET /me/Orders`? Without pagination, cursors, or at least limit/offset parameters, the response can become large and slow, and clients have no clean way to incrementally load history. You could improve this by adding cursor-based pagination and optional filters such as date range or status.

Error behavior is not defined for key edge cases

What does the client see when some requested items are out of stock, the delivery location is not serviceable within one hour, the idempotency key conflicts with a different payload, or the order is still processing? Right now the routes are listed, but there is no status-code/error-shape contract, so clients cannot reliably distinguish retryable failures from user-correctable ones. You could improve this by defining a consistent error body plus expected codes like 400/404/409/422/429/503 and retry guidance.

Inventory service is described in the flow but missing from the actual HLD

The end-to-end ordering story relies on the Order Service calling an Inventory Service for validation and reservation, but that component is not present in the diagram or connections. Have you considered where the reservation logic actually lives and how it scales under 5K concurrent orders? If it is inside Order Service, show that explicitly; if separate, add it and its DB interaction so the write path is unambiguous.

Postgres is the main bottleneck for concurrent reservation-heavy writes

Have you considered what happens when many users order the same hot items at once? The design pushes all inventory decrements, hold creation, order writes, and status updates through a single PostgreSQL primary. At the stated concurrency, hot rows for popular product/DC combinations can become lock contention points and the primary becomes the first scaling limit. You could improve this by calling out partitioning/sharding strategy for inventory, careful row-level locking semantics, and how hot-item contention is handled.

Single points of failure are not addressed for core stateful components

What happens if the PostgreSQL primary, Redis cluster coordinator, Kafka broker set, or Elasticsearch node handling queries fails? The diagram shows replicas for reads, but failover/write continuity for the primary transactional path is not described. Without a concrete HA story, order placement can stop entirely on a primary failure. You could improve this by specifying leader failover for Postgres, multi-node Kafka/ES deployments, and how services reconnect and recover.