Architecture overview

• Architecture

  • Presentation slides: Design group chat

  • Initial architecture

  • Improved with message bus

  • Connection layer

    • Components

    • Responsibilities

    • Motivation for separation from business logic layer

  • Session data

Architecture

Presentation slides: Design group chat

Initial architecture

• Cons:

  • Hard to maintain and extend. All logics are centralized in a single app.

  • Perf bottleneck. All communications between connection and logic layer are synchronous. Different components within logic layer might have different performance.

Improved with message bus

• When the size of group is big, connection service will become a bottleneck because:

  • When users become online/offline, write pressure to connection service

  • When messages need to be pushed down from the server, it needs to check the online status within the connection service

• Optimization

  • Each connection service cluster doesn't need to maintain a global user online/offline status storage. Only maintain the online/offline users connected to the connection service cluster.

  • Subscribe to a message queue

Connection layer

Components

• Please refer to load balancer architecture section

Responsibilities

• Keep the connection

• Interpret the protocol. e.g. Protobuf

• Maintain the session. e.g. which user is at which TCP connection

• Forward the message.

Motivation for separation from business logic layer

• This layer is only responsible for keeping the connection with client. It doesn't need to be changed on as often as business logic pieces.

• If the connection is not on a stable basis, then clients need to reconnect on a constant basis, which will result in message sent failure, notification push delay.

• From management perspective, developers working on core business logic no longer needs to consider network protocols (encoding/decoding)

Session data