Loading...
-User can see other employee shifts
-User can offer to trade shifts
-User can accept or decline offer to trade shifts
-Consistent for shift trading(once shifts are traded that is consistent)
-Available to see shifts
-User isn't overwhelmed with trade requests
-Low-latency no more then a couple seconds to trade shifts
IF we expect around 10000 employees at most making 2000 trade shifts per day making most changes during 1-2 let's say the server should be able to handle 1000 shift trades per hour so it can handle the max of 2000 and keeping track and reading 10000 shifts. Each time a trade it made the database should be updated so the following users have an appropriate updated option of shift trades so that's at most 2000 writes per hour.
GET /shifts
{get current shifts)
POST /trade
{make a trade offer}
POST /trade/id
{accept a trade offer}
Users:
id
more_data....
Shift:
id
userid
time_start
time_end
status: open | pending
trade:
id
shift
user1
user2
status
Two services: One for fetching shifts from the database and one for receiving trade requests and responses updating the shift and trade database
User makes a request to see the available shifts to trade
User makes a trade request
That request checks if the shift is available and then sets the status to pending before using the notification service for notifying the employee of the potentially traded shift
If the user accepts the trade then it updates the employee of the shift and sets the trade to accepted
We can index the shifts database by time and day
Use a key-value store for the shifts where keys are the days and times of the shifts since that is how people will be searching for shifts
Have a queue for the trade requests to people
Redis lock to serve as the way to not use pending shifts in trades, meaning when a user requests a trade and that shift is available still then that shift is set to "pending" so now it can't be requested for a trade (there should also be a user request queue so that people aren't constantly seeing shifts that are using outdated info) once that trade is either accepted or rejected then it can be set back to "open"
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?