Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 13 Next »

The Framework proposed in this space (Alex Xu) is applied to propose a design : Getting started - a framework to propose...

Introduction

A chat performs different functions for different people. It is important to explore the feature requirements.

Step 1 - Understand the problem and establish design scope

Kind of chat ? 1 to 1 or group chat ?

both

Mobile or Web app ? or both ?

both

Scale of the app ? start-up or massive scale ?

massive scale : 50 millions per day of active users.

Limit for a group chat ?

Max 100 people = small group.

Features ? Support attachment ?

1 on 1 chat, group chat, online indicator, ONLY supports textes messages.

Limit of text message ?

Less than 100 000 characters long.

End-to-end encryption required ?

Not required for now, but maybe.

Chat history ?

Forever

Push notifications ?

Yes.

Online presence ?

Yes.

Multiple device support ?

Yes, can be logged in multiple accounts at the same time.

On this page.

Step 2 - High-level design

For a chat service, the choice of the network protocols is important : HTTP connection could be a good option on the server-side, but the problem occurs on the client-side. There are 3 techniques to simulate a server-initiated connection: polling, long polling and WebSockets.

See polling & long polling in the page References & Glossary for chat system.

WebSockets is the most common solution for sending asynchronous updates from server to client. WebSockets (WS) is used for both sender and receiver sides.

High-level shows 3 major categories : stateless services, stateful services and third-party integration. High-level architecture is already scalable because a single server design is a deal breaker (single point of failure).

Client maintains a persistent WebSocket connection to a chat server for real-time messaging :

  • Chat servers facilitate message sending/receiving.

  • Presence servers manage online/offline status.

  • API Servers handle user login, signup, change profil, etc.

  • Notification servers send push notifications.

  • KV Store to store chat history : when offline, user see all previous chat history. See the page References & Glossary for chat system - Storage.

Step 3 - Design deep dive

Service Discovery

Message Flows

Online Presence

Step 4 - Pros & Cons

  • No labels