Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
User Management - User Registration and Authentication
Profile Management
Schedule a meeting
Cancel a meeting
Send Meeting invitations
Real time notifications for meeting reminders
Search for past and upcoming meetings
List non-functional requirements for the system...
1) System should
Estimate the scale of the system you are going to design...
1) System should be highly available
2) System should be fault tolorent
3) System should have low latency
Define what APIs are expected from the system...
Post -/v1/user - This api is used to create a user
PUT /v1/user - This api is used to update the user details for profile management
Post /v1/meeting - This api is used to schedule a meeting
DELETE /v1/meeting - This api is used to delete a meeting from user calender
GET /v1/meeting This api will be used to search a meeting from the scheduled meetings.
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...
1) Sql databse works well for transactional loads when sysetm needs to guarantee acidity so we will be using sql databses
Meeting table This table will have meeting title ,meeting agenda,meeting participants,startTim, endTime
As both the tables contains many to many relationship so we will normalize them by creating an junction table which will store the meeting id and student id
Using junction table we can normalize tables
New schema for these tables are
CREATE TABLE User (
UserID INT PRIMARY KEY,
userFirstName VARCHAR(100),
userLastName VARCHAR(100),
emailID VARCHAR(100)
);
CREATE TABLE Meeting (
MeetingID INT PRIMARY KEY,
meetingTitle VARCHAR(255),
meetingAgenda TEXT,
startTime DATETIME,
endTime DATETIME
);
CREATE TABLE User_Meeting (
UserID INT,
MeetingID INT,
PRIMARY KEY (UserID, MeetingID),
FOREIGN KEY (UserID) REFERENCES User(UserID),
FOREIGN KEY (MeetingID) REFERENCES Meeting(MeetingID)
);
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...
Each request is routed to a load balancer, which forwards it to the appropriate application server. For user-related actions, the load balancer directs the request either to the Create User Service (for user creation) or to the Profile Management Service (for profile updates). When scheduling a meeting, an event is published to Kafka, making the system asynchronous and highly scalable the Meeting Service processes the message to update the database. Notifications are handled using Amazon SES for emails and Twilio for SMS. Each notification service sends messages to a queue, from which the respective messaging or email service retrieves and processes the messages to perform the necessary actions. By replicating messages across different Kafka brokers and their partitions, we can enhance data durability and ensure high availability
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...
Each request is routed to a load balancer, which forwards it to the appropriate application server. For user-related actions, the load balancer directs the request either to the Create User Service (for user creation) or to the Profile Management Service (for profile updates). When scheduling a meeting, an event is published to Kafka, making the system asynchronous and highly scalable the Meeting Service processes the message to update the database. Notifications are handled using Amazon SES for emails and Twilio for SMS. Each notification service sends messages to a queue, from which the respective messaging or email service retrieves and processes the messages to perform the necessary actions. By replicating messages across different Kafka brokers and their partitions, we can enhance data durability and ensure high availability
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...
Each request is routed to a load balancer, which forwards it to the appropriate application server. For user-related actions, the load balancer directs the request either to the Create User Service (for user creation) or to the Profile Management Service (for profile updates). When scheduling a meeting, an event is published to Kafka, making the system asynchronous and highly scalable the Meeting Service processes the message to update the database. Notifications are handled using Amazon SES for emails and Twilio for SMS. Each notification service sends messages to a queue, from which the respective messaging or email service retrieves and processes the messages to perform the necessary actions. By replicating messages across different Kafka brokers and their partitions, we can enhance data durability and ensure high availability
Explain any trade offs you have made and why you made certain tech choices...
1) Scaling sql database is very difficult nosql database can help
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?
1) Introducting messing scheduling assisitant can help in meeting scheduiling.