Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
Estimate the scale of the system you are going to design...
Define what APIs are expected from the system...
POST: api/createAccount (username, password, email, first/lastname)
Response status code: 200 or 400 (already registered)
POST: api/login (username, password)
Response status code: 200 or 400
GET: api/getWeatherApi ()
Response status code: 200 or 404 or 400
GET: api/getNotification ()
Response status code: 200 or 404 or 400
GET: api/getPastNotification ()
Response status code: 200 or 404 or 400
PUT: api/changeNotificationSettings()
Response status code: 200 or 404 or 400
POST: api/addLocations (location)
Response status code: 200 or 400
PUT: api/removeLocations (location)
Response status code: 200 or 400
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...
User{
+INT userId (UUID)
+CHAR username
+CHAR password (SHA512 hashed)
+CHAR email
+CHAR notificationPreference
}
Location{
+INT locationId
+INT userId
+CHAR location
}
Weather{
+INT weatherId
+CHAR timestamp
+FLOAT temperature
+CHAR forecast
+BOOLEAN is_severe
+CHAR Location
}
Auth{
+CHAR userId (UUID)
+CHAR jwtToken
+BOOLEAN account_status
+TIMESTAMP last_login
+TIMESTAMP token_expiration
}
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...
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...
Create account:
Client -> UserService -> UserDB -> 200 response
Login:
Client -> AuthService -> UserDB -> 200 response
Get weather Data:
Client -> WeatherService -> WeatherDB -> Client
Severe Weather Wearning:
Weather Service -> Notification Service -> Message Queue -> Client
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...
API Gateway serves a rate limiter, firewall and load balancer that will route the requests to their deciated services.
Weather Service will pull weather data upon request, and will subscribe to the weather data API through third party, and automatically send out an notification if theres a severe weather/natrual hazard wearning.
User DB has read-only worker nodes to distribute the load, worker nodes will transform to leader DB when the master DB fails.
At a large scale, the User DB will be sharded using consistent hashing.
Multiple API Gateways, multiple replicate servers/DBs for disaster recovery.
Explain any trade offs you have made and why you made certain tech choices...
Weather DB is a noSQL DB that will provide lower latency and higher scalability, but the consistency is not as strong as RDS, since the weather data doesnt have to be always consistent, noSQL is a better choice.
The User DB will use consistent hashing instead of hashing based sharding, when add or remove nodes we dont have to rehash every node. If we use hashing based sharding, we have to re-hash every value when a shard is added or removed.
Using Kafka because the notification has to be delivered in real time and Kafka is built for data streaming.
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?