WhatsApp Design Part-2

If you haven’t read part-1, encourage you to read it here.

This article will focus on Profile Service. You can link this article with any service that involves user creation, just the basic structure will change as per the requirement.

Some Basics — Many applications need to:

• Store data so that they, or another application, can find it again later (databases)

• Remember the result of an expensive operation, to speed up reads (caches)

• Allow users to search data by keyword or filter it in various ways (search indexes)

• Send a message to another process, to be handled asynchronously (stream processing)

• Periodically crunch a large amount of accumulated data (batch processing)

Profile Service

It’s an independent micro-service that performs CRUD operation on user. API details:

POST user_id createUser(api_key, name, phone_number, country, location)

POST user_id updateUser(api_key, user_id) (details to be updated in Post body)

GET USER user(api_key, user_id)

Image Service

Responsible for handling operations related to images inside the app. APIs details:

POST image_id upload(api_key, user_id, image) (image — A binary file, base64 data, or a URL for an image.}

GET user_id image(api_key, image_id) (details to be updated in Post body)

SMS/Email Service

It is responsible for handling all the SMS/Email related operations. For example, phone number validation, OTP related operations. APIs details:

sendMessage(api_key, user_id, phone_number, TYPE_OPERATION)

These services internally store the template for each message (SMS/Email Template_Table). When the request comes, they change the variables in the message and send them.

Now, the only thing remaining is to connect them all. Hurahhhh… Let do it!

I always liked to create a flow, here are the steps according to the diagram:

1. User A sends a request to Gateway1 for creating a new user.
2. Gateway 1 already has cached the instances of Profile service and so sends the request to profile service for creating a new user.
3. Profile service sends the ACK to gateway request received and creates the user saves the detail. Unique user_id is generated and send the request to SMS service for validation of phone number.
4. SMS services verify the authenticity of the user and send ACK to the profile service.
5. Once ACK is received, the profile service sends ACK to the gateway which in turn sends ACK to the user.

Points To Remember

Profile service mains internal cache for accessing most frequent users.

Profile service can have a buffer or some data structure for storing records and pushing the records in the database in batches.

For incoming requests services can maintain some type of queue (Problems: head of line blocking, denial of service, etc all these are outside the scope of this article and might be discussed in a future post.)

Important to understand, I think for the above services, we can go for NoSql databases such as Cassandra, dynamoDb because we can support dynamic schema, require eventual consistency, can store data in JSON format. But for Profile service if our schema is fixed and require vertical scaling then we can opt for Relational dbs for Profile Service. The type of database you opt for service totally depends on the requirement of the system.

Thank you guys for reading this article. Please do share feedback and improvements it would be helpful for everyone reading this article.

Link to part-3, click here.