From Simple Polling to Scalable Microservices: JD’s Dongdong IM Evolution

1.0 Birth (2010‑2011)

Initially, Dongdong implemented a basic IM with TCP long‑connection via the Mina framework, HTTP long‑polling using Tomcat Comet, and message buffering in Redis following a producer‑consumer model, which required high‑frequency polling and suffered from latency and scalability issues.

2.0 Growth (2012)

To improve user experience, the system added queuing, file and image support, customer‑service transfer, and quick replies, addressing the overload of customer inquiries during peak periods.

3.0 Explosion (2013‑2014)

The architecture shifted to a service‑oriented model, splitting the monolithic Tomcat application into multiple services categorized by business importance (levels 0, 1, 2) and introducing a dedicated access service for various channels.

Key upgrades included:

Business tiering and core/non‑core isolation

Multi‑data‑center deployment with traffic sharding and disaster‑recovery

Read‑replica databases with automatic failover

Primary‑secondary write databases with rapid switchover

External interface failover or circuit‑breaker

Redis master‑slave failover

MongoDB replacing MySQL for large chat‑record storage

Improved message delivery model eliminating polling

The new delivery model registers client endpoints on connection, pushes messages directly to the appropriate access point, achieving constant latency and easier scaling.

4.0 Nirvana (2015‑present)

Following JD’s reorganization into a group, Dongdong needed to serve multiple subsidiaries. The solution involved extracting a generic IM core, unifying deployment on a single platform, and isolating data per business while sharing code and infrastructure.

Fine‑grained micro‑services reduced code size and dependencies, though they increased operational monitoring complexity. With mature private‑cloud, caching, messaging, and monitoring infrastructure, the micro‑service approach became feasible, supporting thousands of isolated service instances.

A dedicated service‑oriented operations system provides configuration management, traffic monitoring, database/cache access, and runtime isolation, enabling visibility and controllability of service processes.

The final message‑delivery redesign stores messages persistently, confirms delivery before marking success, and treats unconfirmed messages as offline payloads, eliminating false‑delivery while allowing deduplication on the client side.