Design Fitness Coaching Platform
Topic: Design Fitness Coaching Platform
Interviewer: Fahong/Fei
Interviewee: Fahong/Fei
Level: L5 (Senior)
Topic
Mock System Design Interview Summary
Interview Overview
Date: 5/1/2022
Target level: L5 Google/E5 Facebook
Duration: 45 minutes
Topic covered: Design Gymn-gini, fitness coaching platform
Drawing tool used: excalidraw
Requirements
Functional requirements
User: gym owners, trainers, trainees
Owners can register rooms and trainers
Trainer: host a class, one time/ recurring. For now just assume one time class
Payment: future requirement / good to have
Most gym owners have a waiting list for full classes
Non functional requirements
Startup MVP
Low traffic
System Design
Can start with mySQL due to low traffic
Room: RoomID, location, …
Class: limit, id, roomID, peopleID, startTime, endTime
Enrollment: id, peopleID, classID,status: succeed/fail, enabled, CRUD
Status: waitlist: pending
Account: peopleID, name, email, type, …
Trainer: registered,
Host class: choose a classroom, check the availability, check the class table to show current time treemap room
RoomAvailability: the time slots are free or not
Create a new class, weekly/monthly into class table
Friday 7pm-9pm
Update? check room is free? Other time
Before we publish, we can update the time.
Cancel before the class starts
Payment: not discuss now
External APIs
System design
Trainee:
registered
enrollment:
classId, peopleId,
status
Happy case:
worst: class IS FULL:
classRemains: classId, remaining
cancelled:
people in wait
Timing: rabbitMQ deadletter. Timing: 2 days
FIFO, wait list has a sequence, sorted by time.
Option 2:
Email to people to ask them for confirmation
MySQL:
Timing event to check pending status
Timing job: can check if a class is valid or not
Class waiting 2 days get expired
Q: one person canceled registration. Now you need to notify people on waiting list
Q: Java backend service vs RabbitMQ
A: for startup, I hope to provide simplify the solution. One with RabbitMQ, one without RabbitMQ
Batch service: pending status. Runs every 1 hour to pick up the expired.
When people register successfully, we can decrease class remained
When people cancel, we can increase class remained immediately
Q: what are future work to scale up?
A: (1) do we need to support online, we can support unlimited size
(2) payment features, payment status and exception handling
(3) micro services, assign to different teams.
(4) Web, mobile - load balancing, nginx
Interviewer and Audience Feedback
Interviewer
Detail design
Some structure has not been drawn yet
RabbitMQ, message queue, should have publisher and subscriber
Talked about java backend service
Ideally add rabbitMQ/message queue after we think of this implementation
Time is limited. Ideally draw major components at the beginning. Then we can discuss the most important features. Users can register, create classes, registration, cancellation, rebook.
Interviewee
The system is closer to feature implementation, not as close to distributed system
Most answers are around the features
To improve: organization and diagrams
Was going to design something simple, e.g. no rabbitMQ.
Brought up existing solutions.
I tried to simplify
Audience
System design
Try to clarify the requirement
Collected a lot of requirements
Try to write a summary
How many people are use
50 people - 100 people
We try to clarify the requirement
Use case
Github: want to manage daily activity
Try to provide a workable solution
==
Interviewer: requirements
Service facilitating gym owners, trainers, and customers life
Similar websites: vagaro.com, gymmaster.com, strava
Functional requirements
Users can register/unregister accounts with email dresses and/or phone numbers
Users can create/read/update/delete classes
Users can book/cancel classes
Users can join waiting lists for classes
Users can get notification on upcoming and outgoing events
No functional requirements
High availability
Strong consistency
Low latency
High-level design: major components + APIs
As broad as possible for major components
as accurate as possible for APIs
design tradeoffs (REST API vs graph APIs)
Detailed design: use cases + data models
User register an account
user create a class
user book a class
user cancel a class
DB, cache, message queue
Key knowledge/tests
Architecture: monolithic app vs microservice
Database: sql vs no-sql, time-series, declarative partitioning
Cache: redis cluster vs sentinel
Message queue: publisher/subscriber
Development, test, deployment/integration: web host services AWS/azure/GCP/digitalOcean
API: REST
Scale:
1-2 gyms to 1M
How big do you want to target
==
Change data capture
Framework, mysql, binlog to follow the change
===
User may delete their own account
Then the classes can become available
==
How to handle room vs class
Reserve room, add class, then the room may be lost
We can lock the room entirely, or lock the time fragment
We can use a unique key structure to let the database detect the conflict.