Here’s an iterative technical question suitable for a Software Engineer

interview:

---

Intro:
You're designing a simplified **Order Management System (OMS)** for a
restaurant.
### **Interviewer Question**:
**"For the given scenario, can you walk me through how you would design
this system step by step?"**

### Discussion Points:

- Database schema evolution (e.g., for audit trails).
- API versioning and backward compatibility for order modifications.
- Use of messaging systems (e.g., Kafka or Pub/Sub) for real-time
notifications.
- Scaling strategies for high-order volumes.
- Handling eventual consistency across systems (e.g., client vs. kitchen
updates).

The goal of such questions is to evaluate your ability to design a system

incrementally, considering trade-offs, scalability, and resilience at each
stage.
This step-by-step approach demonstrates problem-solving skills, scalability
considerations, and resilience in design.

Scenario
Functionality/Requirment Question Answer
### **Step 1 - Basic 1. **First Iteration**: ### **Iteration 1: Basic API De
Functionality**: - "Start by designing a **Interviewer**: "Design an AP
**Design an API to place an basic API to handle retrieving orders."
order.** placing and retrieving
- Requirements: orders." **Answer**:
1. The API should accept an - **Follow-up**: "What - **API Endpoints**:
order containing items, database schema 1. `POST /orders`: To create a
quantities, and a table would you use to store 2. `GET /orders/{id}`: To retri
number. the order information, ID.
2. The system should store and why?"
the order in a database and - **Database Schema**:
return a unique order ID. ```sql
 3. Orders should be Orders Table:
retrievable by the order ID. - id (Primary Key, UUID)
- table_number (INT)
- items (JSON or normalized re
items)
- total_price (FLOAT)
- created_at (TIMESTAMP)
```

- **Flow**:
1. When a user places an orde
validate the input (e.g., check
2. Calculate the total price of
3. Save the order in the datab
order ID.
4. For `GET /orders/{id}`, fetc
return the details.

**Follow-up (Database Choice)

- "I’d use a relational database
as it offers strong ACID guaran
ensuring the integrity of orders
### **Step 2 - Adding 2. **Second
Capability Y**: Iteration**: ### **Iteration 2: Adding Orde
**Extend the system to allow - "Now, let’s Capability**
order modifications.** extend this. How would **Interviewer**: "Now, allow us
- Requirements: you allow users to while keeping an audit trail."
1. Add functionality to modify an order after it
update an existing order (e.g., has been placed while **Answer**:
change quantities or keeping an audit trail - **New API Endpoint**:
add/remove items). of changes?" `PUT /orders/{id}`: To update
2. Ensure modifications don't - **Follow-up**:
lose track of the original order "How would you handle - **Updated Database Schema
details for audit purposes. conflicts if two users ```sql
3. Design how the system try to update the same Orders Table:
should handle conflicts if two order simultaneously?" - id (Primary Key, UUID)
clients try to modify the same - table_number (INT)
order simultaneously. - items (JSON)
- total_price (FLOAT)
--- - status (ENUM: 'active', 'mod
- created_at (TIMESTAMP)

Order_Audit Table:
- audit_id (Primary Key)
- order_id (Foreign Key to Ord
- old_items (JSON)
 - old_total_price (FLOAT)
- modification_timestamp (TIM
```

- **Flow**:
1. When a modification reque
/orders/{id}`, fetch the origina
2. Save the original details to
before applying changes.
3. Update the `Orders` table
4. Return the updated order d

**Conflict Handling**:
- Use optimistic locking by add
the `Orders` table. If the versio
doesn’t match the current vers
the update and notify the user.
To avoid malisouce clients man
1- ETags , hash-based appro
public/private key
2- Have the server perform
database to check the ve

3. **Third Iteration**:
### **Step 3 - Adding - "Finally, add a real- ### **Iteration 3: Adding Rea
Capability Z**: time notification **Interviewer**: "Now, add a n
**Add support for real-time system for the kitchen. kitchen to receive updates in re
notifications to the kitchen.** How would you design
- Requirements: it to ensure reliability, **Answer**:
1. The kitchen should get even if the kitchen - **Proposed Design**:
notified whenever an order is system goes down 1. Publish an event to a mess
placed or modified. temporarily?" RabbitMQ, or Pub/Sub) whenev
2. Notifications should be - **Follow-up**: "What modified.
reliable even if the kitchen would you do if the 2. The kitchen system subscri
system is temporarily number of orders to receive notifications.
unavailable. grows to thousands per
3. Design how you'd scale second?" - **Flow**:
the notification system if the 1. Upon `POST /orders` or `PU
number of orders grows an event message (e.g., `Orde
significantly. `OrderUpdated`) with order de
2. Publish the message to a to
3. The kitchen system consum
topic and processes them.

- **Handling Reliability**:
- If the kitchen system is dow
retains the messages.
- Configure message acknowl
delivery.

- **Scaling**:
- Use a distributed message b
throughput scenarios.
- Partition the topic by `table_
parallel processing.

**Follow-up (High Volume)**:

- "For thousands of orders per s
1. Use Kafka with adequate p
2. Batch messages for efficien
3. Implement horizontal scalin
and consumer sides."