> For the complete documentation index, see [llms.txt](https://eric-zhang-seattle.gitbook.io/mess-around/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://eric-zhang-seattle.gitbook.io/mess-around/scenarios/productoverview/architectureoverview.md).

# Architecture overview

* [Architecture](#architecture)
  * [Presentation slides: Design group chat](#presentation-slides-design-group-chat)
  * [Initial architecture](#initial-architecture)
  * [Improved with message bus](#improved-with-message-bus)
  * [Connection layer](#connection-layer)
    * [Components](#components)
    * [Responsibilities](#responsibilities)
    * [Motivation for separation from business logic layer](#motivation-for-separation-from-business-logic-layer)
  * [Session data](#session-data)

## Architecture

### [Presentation slides: Design group chat](https://docs.google.com/presentation/d/1USZsFZDCY9kUosPrSSI4WaDN4koqe801p0MjPV_1n5U/edit?usp=sharing)

### 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.

![](https://1010073591-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk8dv8Mfudl_6ziUzDf%2Fuploads%2Fgit-blob-095a900aa7c4abb7cbca4f572aceb1e412a56248%2Fim_architecture_overview.png?alt=media)

### Improved with message bus

![](https://1010073591-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk8dv8Mfudl_6ziUzDf%2Fuploads%2Fgit-blob-9c48bd4caad8d6e5bd0da0b691d8a045378fc3bb%2Fim_architecture_improved.png?alt=media)

* 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](https://eric-zhang-seattle.gitbook.io/mess-around/network/loadbalancer#multi-layer)

#### 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

![](https://1010073591-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk8dv8Mfudl_6ziUzDf%2Fuploads%2Fgit-blob-946b1f620e3b05626cf5ac8a9ec41e0dc82991aa%2Fim_session_data.png?alt=media)