Elemental System Designs
What is this?
Elemental System Designs is an open source project to document system architecture design of popular apps and open source projects that we want to study. The project focuses on the high level abstraction architecture based on use cases of an app that we can observe while using them in real life.
We will focus on features with high-impact of the selected apps, while proposing high scalable and resilient architecture that could scale infinitely. We welcome anyone who is actually in the same field as the app of proposed architecture to give us ideas around industry specific bottlenecks and your solution to the problem.
What is System Design?
System Architecture Design, often called System Design is a conceptual representation of the components and subcomponents that reflects the behaviour of the system as a whole.
System Architects are who make decisions on components to use based on the use cases and requirements given by the business, and consider trade-offs and bottleneck while designing a system.
What I cannot create, I do not understand. — Richard Feynman
I am writing this project for me to better understand system architecture of various popular apps that I use daily. While the system design proposals are hypothetical, we bring industry best practices in the proposals, and have them available for anyone who is interested in pursuing the field of system architecture designs as references.
I believe a good architecture is the key to delivering a successful project. A good architecture is required even if you are building a side project or a system for a company while being paid. Once a good architecture is available in front of you well documented, you are more confident and faster as a programmer to hit the deadline of delivering an application (or even a feature within a large ecosystem).
- [WIP] Dropbox
Structure of system designs
1. Introduction to the system
This section briefly explains the app. Any useful text from the app's official webiste or Wikipedia would fit for this
2. Use cases and Requirements
This section details use cases of the app that we are studying. And followed by requirements for this system design.
When picking requirements, we try to pick the most high-impact features of the app, for example in Tiktok example, we've picked viewing videos, uploading videos, and receiving personalised feeds.
- Identify traffic and data handling at scale
- Scale of the system such as requests per second, request types, data written per second, data read per second
- Special system requirements such as multi-threading
4. Drawing Application Architecture Diagram
What is Application Architecture Diagram?
An application architecture diagram comprises a high-level overview of the components and fundamental interactions within the system, e.g. microservices, databases, etc. The application architecture diagram primarily addresses the “What” in relation to the system.
We want to keep our system designs to show an abstraction of important components. The diagram should contain following features
- Be simple
- All important components of the system to facilitate the requirements
- System boundaries
- In an architecture diagram, it is a concept line that divides the system you want to study from 'everything else
- It is to include elements that you are interested / specified in the use cases / requirements
- Show system interactions
- Use simple shapes and lines to indicate process flows and the way the different elements communicate to each others
- Include useful annotations
- Add helpful explanation to critical pieces of your diagram
In the diagram, we want to include following components
- Application service layers
- Data storage layers
- Usually a scalable system includes load balancer, event stream, queue, databases (master/slave, replication or sharding model) and in-memory key-value stores such as Redis
For the icons used in the diagram, please check this link
5. Component Design
Component + specific APIs required for each of them.
- The project focuses on the high level design, we should use component design section to enhance the detail that could be too vague in the application architecture diagram. This is the section to write anything important per component level
Database schema design
- A simplified database schema design that focused on only important ones in relation to the requirements and use cases
6. Understanding Bottlenecks
- Describe any industry specific bottleneck (e.g. security concerns in financial applications)
- Maybe the application needs a CDN? Load balancer? Data is so huge so database should be sharded?
- Maybe the application needs complex query to fetch data, caching the result somewhere such as in-memory cache store would be beneficial?
Provide suggestions on adding more power to each component where it's necessary and important.
Wherever possible, service components should be horizontally scalable.
Can the design take advantage of any following caching strategies?
- Can any component take an advantage of application layer caching LRU / LFU?
- Database layer caching?
- In-memory caches such as Redis or Memcache?
- CDN to cache static assets?
Please check CONTRIBUTING.md
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!