System requirements

Functional:

1. A customer is able to search for groceries and able to order groceries from nearby stores.
2. Ability to add products to the inventory in the system
3. Ability for nearby stores/distribution centers to look up the quantity requested by the customer, and be able to service the same.
4. Ability for orders to be assigned to delivery partners to deliver the order correctly at the customer's location.
5. Ability to send notification to customers about delivery updates/status/promotions etc.

Non-Functional:

1. The system should be highly scalable, so as to handle a high number of requests.
2. The system should update the number of the inventory very accurately and consistently so as to be able to serve the customers correctly with the requested number of items.
3. Availability requests should be fast enough (<100 ms) to support functionalities like search.

Capacity estimation

Let's assume that our system should be efficient enough to handle 10 million orders per day, which will be about 10*1000000/24/60/60 which is roughly 120 orders per second.

Let's assume there are about 10 queries through which user searches, and only 5% of user end up ordering the product.

Therefore the total number of queries per second ~~ 120*10 /0.05 = 24000 queries/second, which is a sizeable query.

Also the delivery times to deliver a product from a store or distribution center to the customer should be limited to a maximum of 1 hour

Peak hour orders = 5x than usual ~ 5*24000=120000 queries/second.

API design

Creating a Product/Item/Inventory in the System.

1. There will be an API to Create product in the system . POST/product/ endpoint with details of the product, which store it is available at, and number of items available.
2. There will be an API to search for the product in the system, given the customers location. Get/SearchProduct/{id}/latitude = x&&longitude=y.
3. There will be an API to create an Order by the customer. POST/Orders with the order details in the body.

Database design

For this system design, we need to be able to do atomic transactions, for example if two users are trying to order the same items at the same time, one of them will be rejected if inventory is unavailable.

We also need to be able to update the items and inventory count, via joined tables, once the order has been created.

I would chose a MySQL database for the same. Some of the tables that will be used are.

1) A product Table - Product id, product name

2) Distribution center table - The id and location details of the distribution center.

Distribution center id, Latitude, Longitude

3) Inventory table - to store the amount available for each product belonging to a particular distribution center.

Id, product id, distribution center id, quantity available.

4) Users table - to store user details.

user id, user name, list of addresses, phone number, date created, isActive

5) Orders table - to store details of the orders created by users

order id, user id, order status, total order amount

High-level design

1. Product Catalog System - This will majorly build the product catalog . Accept a request to add a product to the system. This will involve the Product Service.
2. Order Management System - This takes care of user requests to place an order via the Order Service, make the payment via the Payment Service, Assign the delivery for the order via the delivery service, send notification to the user via the notification service.
3. User Service - to add users to the system, update and delete users as and when required.
4. Availability Service - Fetch the inventory availability for the nearby distribution centers.
5. Location Service - To fetch the optimal distribution centers or stores located within the proximity of the user co-ordinates.
6. Admin DashBoard for internal use.

Request flows

1. The user makes a search request for a particular product.
2. The availability service gets the above request made by the user. It has the user's co-ordinates, X and Y.
3. The availability service will trigger a request to the Location service to fetch the distribution centers/stores that are within x kms of the co-ordinates X and Y.
4. The location service returns the Distribution center Id list to the availability service and that will then create a query for the Database to fetch the inventory availability for the related products at the list of Distribution center Ids.
5. Once the database has returned the list of the availabilities, the set of Distribution centers with the list of the Products are shown to the user.
6. The user then selects a particular Distribution Center, and adds the products whose availabilities have been returned and then places an order .
7. After the order has been placed, the Delivery Service will assign a delivery partner to the Order based on the proximity of the partners to the customer's location.
8. Once the delivery partner has been assigned, the notification service will send a notification to the user about the status of the delivery, and to track the delivery.

Detailed component design

1. Customer should be able to search the availability of products within their location. In order to ensure that the lookups from the database is faster, we can shard the database by location/region Id, so that the lookup for a particular product belonging to a region goes to only a subset of the inventory rather than the entire inventory dataset. To ensure a strong write consistency, we can write only to the master/leader and for reading, we can read from the read replicas. The reading will anyway happen only at the sharded inventory .
2. While doing the lookups for availability, we can also incorporate time based on traffic conditions with the location service. There could be an additional time estimation service, that can filter out the distribution centers based on the actual / estimated time for a delivery partner to to deliver the order.

Trade offs/Tech choices

1. For this system, as much as data is important, it is assumed that the consistency and the accuracy is more important than the latency. Hence we choose a relational DB in order to make use of the ACID properties, and provide for atomicity and atomic transactions. While doing the above, and having all tables in one database, we are also introducing a strong coupling between tables, and limiting usage of any other optimal data stores. However, for this system, the RDBMS would be a good solution.

Failure scenarios/bottlenecks

1. Any of the involved services can be scaled horizontally to avoid failures and bottlenecks.
2. The RDBMS database that we choose follows a master slave replication model to replicate the data across multiple replicas. We use the query reads from the read replicas and the writes to a master node.
3. We have also introduced sharding by location id, in order to optimise the reads.

Future improvements

1. We can add special discounts/offers or surge pricing during peak time
2. We can add rewards scheme for users ordering frequently.
3. We can add special discounts for items that are expiring within 2 days.