Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

1. Get list of employees for a shift.
2. Send trade request to a list of employees. Ensuring that once one employee accept the request, it will be unavailable for other employees.
3. Employee involved will receive a notification when trade is requested, accepted or approved or times out.
4. Once employee accept the trade request, email/notification will be sent to manager to approve/reject this trade.

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

Consistency will trump over performance.

Reliability will be high

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

Read/write ratio will be 50/1

Spike will be 10x average (on monday morning shift)

10000 employees and 3 shifts per day

Each record (shift ID, employee, date, time, status) ≈ ~500 bytes

10,000 employees × 3 shifts/day × 365 days = ~11M shifts/year

11M shifts/year × 5 years = ~55M records

~55M × 500 bytes = ~27.5 GB raw

swap request - 1-2% shifts swapped so 300 swaps per day.

We will archive the data in DB by the end of the month.

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

GET /shifts?date_from=...&date_to=...&status=available

GET /shifts/:id/swap-recommendations — get compatible shifts scored by time proximity, skills, location

GET /employees/shift/{shiftId}/date/{date}

POST /employees/shift/{shiftId}/date/{date}

Body {employeeIds}

POST /employees/shift/{shiftId}/date/{date}/decline

POST /employees/shift/shiftId/date/{date}/accept

POST /manager/employee/{employeeId}/shift/shiftId/date/{date}

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Load Balancer - Based on the traffic, balances load.

API Gateway - Handles OAuth/JWT authentication and authorization

Recommendation Service will recommend which employees should be approached for trade based on there skills and shift availablility. This uses Redis Cache to handle the load on DB

Notification Service - Email Notification will be sent out to all the employees and once employee accept the request, the notification will be sent out to there manager. This will be handled with the help of web socket to handle real time updates.

ETS - Employees acceptance, Manager approval and other write operations will be handled by this service. The interaction between ETS and notification service and Recommendation service happens with the AWS SQS

Database - Since the load is less, we can use RDB like PostgresQL.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

Employee Table - EmployeeId, other employee details.

Manager Table - ManagerId, manages which employee

Shift Table - ShiftId, EmployeeId, date, Shift Time

SwapProposals - id, requesting_emp_id, receiving_employeeId, status, receiving shift, manager_id , expires_at, created_at etc.

Archived_Swap_history -> Everymonth move the swap history to archive.

We will use PostgresQL

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

Recommendation Service gives recommendation to an employee for all the shifts available.

This shift data is fetched from the Redis Cache, and for a particular employee, this information gets invalidated everytime that employees request is approved.

To handle the load on DB, communication with notification service and recommendation service happens asynchronously.

If recommendation service goes down, then all the request will be stored in the queue till 14 days, we will handle this in the UI to send graceful message to the user but if a request is taking more time, we will use circuit breaker pattern to avoid passing unnecessary loads to downstream servers.

If for some reason, the notification service goes down, then all the request will be stored in the queue till 14 days and all the notifications will be processed once the service comes back up.

To avoid race condition, redis distributed lock will be used. The Swap Proposal will have a status field and once a employee accepts it, other employees will not be able to accept it.