System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1. When customers or business logs in to the system they should be able to view the status of the order in real time.
2. Customers should be notified for every state change of the order
3. Customer should be notified when they placed the order
4. Customer should be notified when the business receives the order
5. Customer should be notified when the business shipped/sent the order
6. Business should be notified when the customer places the order
7. Business should be notified when the customer receives the order.

Non-Functional:

List non-functional requirements for the system...

1. System should always be available to track the order
2. System should be reliable
3. System should reflect the right status of the order.
4. system should return the status in near real time with low latency

Capacity estimation

Estimate the scale of the system you are going to design...

1. 500M users using the system to know the status of the order
2. Each order meta data is 500MB
3. Each user can have 10 orders a week which is 520 orders a year so 520 * 500M ~250B orders
4. We need 500MB * 250B orders storage to store the data of all the orders
5. No of users fetching the order tracking status will be 500K per day which is 350 requests per sec.
6. Each requests takes 20ms to fetch the order status which means in 1sec it can process 50 requests
7. In order to process 350 requests per sec, we need 7 PODS.
8. if we get more than 350 request per sec, we need to auto scale.

API design

Define what APIs are expected from the system...

GET - v1/user/order

{

user_id:{user_id}

order_id:{order_id}

}

{

status: {status}

}

DELETE - v1/user/order

{

user_id:{user_id}

order_id:{order_id}

}

{

200 OK

}

Get the status of the particular order of a particular user

status can one of {MERCHANT_RECEIVED, PROCESSING, SHIPPED, DELIVERED, CANCELLED}

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Order table

order_id

user_id

actor_id (business|customer)

status

creation_time

updation_time

Same order table will be updated by business and customers.

Table is sharded on user_id and partitioned on order_id and indexed on status

1. customers will try to write to DB
2. business will try to update at the same time.
3. customers will also try to read from DB

This is a read heavy system

1. We need to distribute the load between read and write replicas
2. Writes fill happen on order table sharded on user_id and partitioned on order_id
3. Reads will happen on read replicas.
4. Read replicas will eventually be consistent.

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

1. Client service when receives the order, writes a row into order table and update the status to "RECIEVED"
2. publishes a message to Kafka topic. Kafka topic is partitioned on order_id. so that all the events are ordered.
3. Notification service subscribe to kafka topic and pulls the record and send the latest status to the user.
4. Business service updates with SHIPPED
5. Both business and notification services subscribe to kafka topic.
6. business service will only listed to received status of the event payload
7. Event payload -

{

order_id

user_id

event_type : {RECIEVED|SHIPPED|DELIVERED}

}

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

There are two ways user can get the status of the order

1. Pull Model - User hits the Get endpoint. /v1/user/order -> it will query the database and return the status.
2. Push model -> Notification service will push the notification/current status to the users via push notification.
3. websocket gateway maintains the mapping of active connection and the client.
4. notification service queries redis to get the mapping of websocketserver to client
5. Customer service and business service both publishes the message to kafka after they update the DB.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Bottleneck is if there are any failures while writing DB or if publish to kafka fails or if consumer fails to pick from kafka topic.

The order of the messages is important. SHIPPED message cannot arrive before ORDERED message into the queue.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?