Loading...
The app will be available in mobile phones and as a web application.
The main features are:
Availability is important, so application can be always accessible.
Eventual consistency is acceptable: some time can happen after an activity or goal is recorded until it's available.
Durability of information is also an important requierement.
The system must be scalable as the number of users can increase quickly. There can be spikes in the app ussage that must be supported.
Latency requierements: up to 500 ms is acceptable.
Personal information is managed and must be protected. It's crucial to avoid a user access information of another one.
Estimate the scale of the system you are going to design...
12.500 peack activities submitted per minute
300.000 peak reads / minute
User (80B, with page at 80% and indexes --> 125B)
Activity (50B, with page at 80% and indexes --> 90B)
Goal (70B, with page at 80% and indexes --> 120B)
Storage capacity estimation
Input: user nick and password
Output: session id
Checks user credentials and creates user session including userId and other information
Input: activity type
Output: activity id
Retrieves
Retrieves information from session id
Creates a new activity with information (user id, activity type, start date)
Input: activity id
Otuput:
Registers end date for the activity
Input: optionally a list of activity types, optionally a range of dates, optionally an offset, optionally a max number of records
Output: list of activityes
Searches for activities of the userid of the session that fulfill the input parameters
By default 10 activities are returneed, and for avoiding excessive resources useage, a maximum of 50 can be returned
Input: goal name
Output: information related to goal acomplishment
Retrieves the goal for the user
Retrieves activities related to the the goal for the user
Computes acomplishment
Other APIs for managing goals are ommited for simplicity
For protecting user information, all queries use the user id registered in the user session to prevent retrieving data from other users
User (90B, with page at 80% and indexes --> 125B)
Activity (50B, with page at 80% and indexes --> 90B)
Goal (70B, with page at 80% and indexes --> 120B)
User
Activity
Goal
Activity collection is the one with more accesses and more storage used. It's expected to need 1 TB of data in 3 years. It will be partitioned, initially with 2 partitions.
The partition key is user id
Paswords are not stored plaintext, they are hashed with bcrypt (salting and iterative hashing)
DNS server
Provides IP from hostname.
Load Balancer
Distributes requests to the Web Servers and API Gateways. Provides high availability.
As advanced load balancing / routing will be performed in API Gateway, a L4 load balancer is proposed.
CDN
Serves static content for the web application.
API Gateway
Provides rate limiting. In the future it will perform JWT token validation.
It also routes the requests to available Application Servers
Applicaiton Server
Executes the application backend logic.
Database
Mongo DB database that stores the applicaiton information.
Cache
Stores application session and cache for recently used activities. Reduces DB requests providen performance and scalability. Implemented with Redis.
Monitoring System
Stores metrics
Analytics System
Provides analytical information for making informed decissions
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...
Described in Sequence diagram and Data Flow diagram
Redis is selected because it's well known, has good performance and provides necessary functionality.
For user session information, a TTL will be configured at login ant updated with each user request. The TTL will be the 30 minutes session timeout.
Redis can be scaled
For recently used activities: when a collection of activities is retrieved, it will be stored in Redis with a 10 minutes TTL because the usual pattern is to query them multiple timens in a short period. The cache-aside strategy will be used.
Redis cluster will be used to ensure scalability and high availability, avoiding a significan load increase routed to the database
With the system requierements (high availability, high writing throughput, big ammount of data, eventual consistency, no complex relational queries) a NoSQL is selected. MongoDB fits well with the data structure and requierements.
In order to achieve high availability, the three collections wil be configured with replica sets of 5 elements distributed in 5 nodes in 3 availability zones, allowing a full datacenter failure.
For scalability, sharding will be used for Activity collection. Initially 2 partitions will be in place and more can be added when required.
For writing:
For reading:
Will serve static content as the web application providing good user experience (low latency)
A push approach, updating the CDN in the Continuous Delivery pipeline, when a resource is changed is selected when updates are performed.
Thepending on the resource life expectancy, a customer cache expiration will be configured. For example: images will have longer TTL and main app source code will have a lower one.
API Gateway was included in the solution despite some additional cost, complexity, and latency, because rate limitting is important and in the future it can provide additional features as JWT token validation.
CDN used instead of web servers to deliver static content as the web application is used because:
CDN failure has very low probability and is more scalable / available than having Web Servers for static content.
All the core components will be in high availability mode with nodes in several regions: Load balancer, API Gateway, Application Server, Redis cluster Cache, MongoDB database
In case of global availability acrros multiple regions, DNS could be use to route requests to available LBs in different regions.
In case of short high spikes in writes to MongoDB it may be a bottleneck. Two options are provided:
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
Use an IdP that supports OAuth 2 to manage user authentication and
Option to automatically detect activities and record them in the mobile device. User can modify it later.
Appliction for smartwatch.
Store user information (age, height, weight, sex ...) and provide recommendations according to it.
Allow 2FA for improving control access.
In case of high spikes in writes, a low latency messaging solution, Kafka for example, can be used to temporary store write operations and a pool of consumer will steadelly retrieve and write themo to MongoDB.
For additional security include WAF in the same layer thant the CDN.