business background

Suppose you are currently serving as the CTO of a startup company. Because WeChat does not distinguish between work, life and entertainment, there have been many embarrassing incidents of sending sensitive information (you can make up your own mind) to the wrong person or even the wrong group! The CEO of your company has decided to make an IM tool. In order to distinguish the popular IM needs of WeChat and QQ, your company focuses on secure IM. The competitiveness of this product is as follows: it focuses on private chat and strictly controls the number of private friends, unlike WeChat. , you may need to add WeChat to buy food.

【company background】

1. The technical team has about 10 people, 6 on the back-end, 2 on the front-end, 2 on Android, and not yet on iOS;

2. The backend is mainly Java, mostly P6~P7;

3. The backend has experience in developing and using MySQL, microservices, Redis, etc.;

4. No back-end experience related to big data and recommendation

Basic business scenarios

picture

1. Each user will generate an asymmetric public key and private key through an algorithm;

2. Messages sent by users will be encrypted with the public key, and messages received from users will be decrypted using their own private keys;

3. Only one-on-one chats can be created;

4. Chat messages are “burned after reading” and are only retained for a maximum of 60 minutes;

5. No need to register with a mobile phone number;

6. Each user can have up to 20 friends

Overall architectural idea

The boss said that we will reach 10 million registered users within 3 years. As a CTO, how should you design the architecture?

Shiwan: Implementation is fast, but what if the business develops very quickly and the architecture soon becomes out of place?

Million: The implementation is slower, but it also faces the risk of business development too fast.

Ten million: The implementation may take more than 6 months, but basically there is no need to change the structure within 3 years.

With advanced design, does the architecture really not need to be changed?

picture

1. Changes in business scale

Can design responses in advance.

2. Business diversity

It is impossible to predict what functions will be performed, and business diversity will make it even more unpredictable how large the number of team members will be.

3. Technology development

It is impossible to predict, especially related to legal policies, such as blockchain, localization, etc.

Estimated storage performance for 100,000 users

picture

【register】

100,000 users

【Log in】

Although IM is a relatively active product, since it is a brand new product, we assume that there are 100,000 registered users, 40% of which are active users every day, and 40,000 logins per day.

【add friend】

Each active user has a maximum of 20 friends, and the number of friend relationships is 40,000 * 20 = 800,000 relationship data

【chat】

Assuming that each active user sends 100 messages to 5 friends every day, the number of messages is: 40,000 * 5 * 100 = 20 million, and the data is basically deleted that day, so the number of writes, reads, and deletions can be Estimated to be 20 million

Storage architecture design

picture

Estimation of computing performance at scale of 100,000 users

picture

【register】

Achieving 100,000 user registrations in one year, the registration TPS is very low.

【Log in】

Although IM is a relatively active product, since it is a brand new product, we assume that there are 100,000 registered users and 40% of daily active users. Assume that login time is concentrated in 4 hours in the morning and evening. The average login TPS is: 40,000/14400 = 3.

【add friend】

Each active user has a maximum of 20 friends, and the number of friend relationships is 40,000 * 20 = 800,000 data. Calculated within one year, TPS can be ignored.

【chat】

Assuming that each active user sends 100 messages to 5 friends every day, the number of messages is: 40,000 * 5 * 100 = 20 million;

Assume that every day is concentrated within 3 time periods of 6 hours in the morning, noon and evening (1 hour in the morning, 1 hour at noon and 4 hours in the evening);

• Sending message TPS: 20 million/(3600*6)≈ 1000;

• Read message QPS = Send message TPS, Delete message TPS ≈ Send message TPS

Load balancing of computing architecture

picture

Caching architecture of computing architecture

Scalable architecture design

picture

High-availability architecture design-city data disaster recovery

picture

Why is the IM message data stored in Redis not backed up across computer rooms?

1. Performance issues 2. Consistency issues 3. Cost issues