1. System requirements

Functional:

• The system should have a user-friendly interface
• The users can swap their shifts with colleagues according to the schedule
• The user may choose the appropriate shift in the shift calendar and mark it. Their colleagues approve or disapprove it. Their manager should review changes.
• The users can change the shift two months in advance
• If the manager approves a shift, the user is swapped.
• The users can get the history of their successful shift swap.
• The user uses the client application, in which the user can swap shifts with other employees and view the history of previous shift swaps.
• The users have 2 roles: employee and manager. A manager should approve the employee shift swap.
• The shift swap is a multi-step process: employees agree on the shift swap, and their managers should approve it as well.

Non-Functional:

• The system guarantees compliance with labor laws and fairness measures to prevent favoritism and unequal shift distribution.
• If the user changes the shift in the calendar, they will be notified by colleagues within 100 milliseconds.
• The system stores the shift history for one year.
• The users can see only the other shifts approved by a manager.
•  The system should be able to handle a large number of users.
• The system should be reliable and available even under high load.
• The user can only make the 3 shift swaps per month.
• If two users want to swap the same shift, the winner would be picked up randomly.
• The user can make a shift swap up to one week in advance.
• If the client application loses the connection to the backend, the client retries the last operation by persisting the user data.
• The client application works on mobile and platforms and uses long-polling to get shift swap status.

API design

Here's a breakdown of the essential REST

API for our Employee Swap System.

User service:

PUT /auth/login - authenticate a user

PUT /auth/logout - log out user

POST /auth/register - register new user:

{ "name": "name1"

"email":....

"phone": ...

"employe_id":

"position":

"department":

"manager_id"

}

Employee shift matching service:

PUT /shift_matching/v1/swap/{employee_id1}/{shift_id1}/swap/{employee_id2}/{shift_id2} - try to swap the shift_id1 of the employee_id1 with shift_id2 of employee_id2:

Return :

{ "swap_id"....

"status": IN_PROGRESS,APPROVED_BY_MANAGER,APPROVED_BY_OTHER_EMPLOYEE,CANCELED

"createdAt": ....

}

GET /shift_matching/v1/swap/{employee_id}/status/{shift_id} - return the swap attempt status:

{ "swap_id"....

"status": IN_PROGRESS,APPROVED_BY_MANAGER,APPROVED_BY_EMPLOYEE,CANCELED

"createdAt": ....

}

GET /shift_matching/v1/shift/{employee_id}

return the available shifts for an employee

{[.

'shift_id':

'employee_id':

'start_time':

'end_time':

'last_swap_date':

]}

PUT /shift_matching/v1/swap/{employee_id}/approve/{shift_id} - an employee approves the suggested shift.

PUT /shift_matching/swap/manager/{manager_id}/approve/{shift_id} - a manager approves the suggested shift if both employees agree.

Employee Shift service:

GET /employee_shift/v1/shift/{employee_id}/shifts - get the list of the shifts scheduled by the employee_id:

{ "employee_id":...

"shifts":[

{ "shift_id":....

"startFrom":

"endTo":

'status':

'last_swap_date'

},

....

]

POST /employee_shift/v1/shift/{employee_id}

Persist the new shift for an employee.

body:

{ 'shift_id'

'employee_id'

'start_date':

'end_date':

'status':

'last_swap_date':

}

PUT /employee_shift/v1/shift/{employee_id}

Update the shift information for an employee.

High-level design

See the diagram from the high-level architecture.

API Gateway provides DDoS protection and TLS termination, and routes the requests to the right service nodes.

The user service:

• log in the user and assign them a new JWT.
• log out the user
• register new user

Employee shift matching service:

• query the current employee shifts to swap them. If both employees agree to swap their shifts, it sends the approval to their manager.
• Query the current status of the shift swap
• If the employee's shifts are changed, it sends the updated shift event to Kafka to be received by the Employee shift service.
• Update the employee shift swap status
• Request to persist the shift status to the Employee Shift service with Kafka
• Call the Notification service to notify the user application to confirm the employee shift swap.

Employee shift service:

• store the shift information in Postgres
• receive the updated shift event from Kafka and store the updated shift information to Postgres
• return the shift for employee_id or for all employees

Kafka:

• event streaming platform to process the shift update events.

Notification service:

• Notify user application if it needs to confirm the employee shift.
• Store the employee shift swap status in the Redis

Postgres:

• Hold the user and shift information

Redis:

• cache the employee shift information

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...

Employee shift matching service:

This is essential service and it's used to match the given employee shift. For that the service the Redis structures to hold the employee shift start time for every employee. When someone requests to swap the two employees shift, the service query the Redist startTime from the Redis, verifies that's shifts are available and update the employee shift in Redis. Further the other employee should approve it

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...