The Architecture of Wechat & SMS

WeChat Architecture

Wechat architecture

This is my version of a very high-level WeChat Architecture; There will be a gateway that will take care of authN & authZ, load balance, rate limiting, circuit breaker etc.

Behind the gateway will be a micro-service cluster grouped by business unit, e.g. Moments, IM, Mini Progame. I believe from a very high level. It will look like this. Of course, each unit will be way more complicated than it was in the above diagram.

There also will be some general services shared across the whole WeChat platform, like the file system and notification system. Also, platform services like service discovery and Configuration service.

Besides that, there will be other ops services like Tracing System, Metrics System and Monitoring, marked as purple in the above diagram.

Lastly, we have an analytics platform to collect and analyse data that will help us get better insights.

Student Management System (SMS)

The Requirement

Design an SMS as your graduation assignment/project.

The requirements are

• Accessible through the internet domain.

• Minimum team size: 3 members

• Must be able to support 1000 students.

The Background

Now given you have two teammates.

The tech stack of your team is

• All of you have Java background,

• One PHP expert.

As you are all students, you have a relatively small budget.

The Solutions

Solution 1 - Nginx + Web Server + MySQL (Master + Slave Replication)

Nginx + Web Server + MySQL

Pros:

1. Simple.

The whole requirements are quite simple. We only need to support 1000 students. Even we have two pods here to void the single point of failure. But considering that most requests are reads, we can run one pod most of the time and scale up to two during some special period, e.g. course selection period.

2. Economic.

One server should be enough for our needs.

3. Scalability.

With the docker container, we can easily scale up.

Cons:

1. Development is slow.

For example, changing an icon must go through the whole development pipeline and might cause some unnecessary downtime.

2. Locked into an increasingly obsolete technology stack.

Solution 2 - Nginx + CDN + Web Server + MySQL

Nginx + CDN +  1 docker pod + MySQL (Master + Slave Replication).

We will separate the front end and back end. Each will have its own repository, tech stack and development pipeline.

Pros:

1. Relatively Simple.

The whole requirements are quite simple. We only need to support 1000 students. Even we have two pods here to void the single point of failure. But considering that most of the requests are reads, we can run one pod most of the time and scale up to two during some special period, e.g. course selection period.

2. Independent Deployment.

One server should be enough for our needs.

3. Scalability.

With docker container, we can easily scale up.

Cons:

1. Increase Cost.

Compared with solution 1, we have an extra cost for CDN and an extra development pipeline.

2. Increase operation effort.

With a new separate repository and development pipeline, it will increase the whole operation complexity. Make the whole release more complicated than only one monolith development.

3. Increase latency and failures.

Previously when the front end was tied with the back end, we got the benefit of processing everything together in the server and returning the final result. Now the separation of the front end and back end means the front end and back end aren't that closed anymore, and we need to send requests through the internet to process any actions. Sometimes we might need to send more than one request to finish a transaction, which increases the latency and then the possibility of failures.

Summary

Overall, compared with all the pros and cons, I will propose solution 1.