Build a Scalable Instant Messaging System with CIM: Architecture, Code, and Deployment Guide

CIM Instant Messaging System Overview

CIM (Cross‑IM) is a developer‑focused instant messaging solution that provides a set of reusable components for building horizontally scalable IM services.

Using CIM you can implement:

Instant messaging systems

Message‑push middleware for mobile apps

Massive‑connection middleware for IoT scenarios

The full source code is hosted on GitHub: https://github.com/crossoverJie/cim

Demo

The project includes video demos for group chat and private chat.

Architecture Design

All components are built with SpringBoot. The underlying communication layer uses Netty combined with Google Protocol Buffer. Client routing information, account data and online status are stored in Redis. Service registration and discovery rely on Zookeeper.

Core Modules

cim-server

The IM server handles client connections, message forwarding and push notifications. It supports cluster deployment.

cim-forward-route

The routing server processes message routing, forwarding, user login/logout and provides operational tools such as online user count.

cim-client

The client is a command‑line tool that can start a session with a single command, send group or private messages, and execute built‑in commands.

Process Flow

1. The client logs in via the route service. 2. After successful login, the client obtains an available IM server address from Zookeeper and establishes a long‑living Netty connection. 3. The client sends a special login packet to bind the user ID with the Netty channel. 4. On logout, the client clears its state from Redis and notifies the routing service.

Registration & Discovery

Each IM server registers its IP, port and HTTP port to Zookeeper on startup. Clients watch the registration node to discover available servers and select one via a simple round‑robin algorithm.

Login Logic

The login interface validates credentials, checks for duplicate logins using a Redis set, stores routing information in Redis, and returns the selected IM server address.

Message Routing

Messages are sent to the routing layer via HTTP. The routing server looks up the target user’s server instance from Redis and forwards the message to the appropriate cim-server, which then pushes it to the target channel.

Client Commands

:q

– quit the client :olu – list all online users :all – list all commands (future expansion)

Group chat is performed by typing a message and pressing Enter; private chat uses the format userId;;message after retrieving the online user list.

Custom Protocol

The protocol, encoded with Google Protocol Buffer, contains three fields: requestId (user ID), reqMsg (the actual message), and type (message category). Types include chat, login, and heartbeat.

Heartbeat

Clients send a ping packet every minute to keep the connection alive; the server treats missing pings as offline.

Message Callback

After receiving a message, the client invokes a user‑defined CustomMsgHandleListener bean for custom processing such as persistence.

Summary

CIM is a first‑version prototype that demonstrates the core concepts of a scalable instant messaging system. It provides a solid foundation for developers without prior experience in building such services and can be extended with additional features.