How did we build a domain-independent chat platform?
MessagingHub turns chat into a reusable platform rather than rebuilding it for each product domain. It separates domain-specific authentication and business context from common chat capabilities, allowing chatbot, customer-support, direct, and group conversations to share the same infrastructure. Its policy-driven design, modular architecture, and configurable metadata aim to reduce integration complexity while preserving flexibility. ## Why MessagingHub Was Introduced - Chat requirements vary across chatbots, customer support, one-to-one conversations, and group chats. - Building each implementation independently increases integration points, system complexity, development cost, and the impact of small changes. - MessagingHub is designed as a domain-independent platform that can be adopted by multiple services. - The platform focuses on chat itself while absorbing external requirements through generalized, reusable structures. - It is currently used by a Japanese food-delivery service for users, drivers, customer-service agents, and restaurants. ## Supported Chat Types - **Chatbots:** Delivered through a public web URL embedded in a partner service’s webview. Scenarios are created and deployed through an administrative console. - **Inquiry chat:** A user is matched with a customer-service agent. The partner domain supplies contextual information such as user details and previous consultation history. - The platform is also structured to support direct one-to-one and group conversations. ## Core Platform Policies ### Authentication and User Identification - MessagingHub does not manage user accounts or domain authentication. - Partner systems handle login, registration, permissions, and the decision of whether a user may access chat. - After authenticating a user, the partner requests a connection token and passes it to the client. - The client uses the token to establish a WebSocket connection; unauthenticated direct access is not allowed. - A user is identified by a `client_id`, combining the partner domain identifier with the partner’s user identifier. - Display names, profile images, and `pushToken` values are supplied and updated by the partner system. ### Service Contexts and Room Types - A **service context** defines which roles may communicate, such as: - `Driver2CS` - `Consumer2CS` - A **chat room type** defines the conversation structure, such as: - `USER_DIRECT` - `USER_GROUP` - `INQUIRY_CHATBOT` - `INQUIRY_CHAT` - The combination of service context and room type controls room creation, participation, and message permissions. ### Room Lifecycle and Data Retention - General room states progress from `WAIT` or `PENDING`, to `SERVICE`, and eventually to `DISABLE` or `BLOCK`, where sending messages is prohibited. - Messages and potentially identifying data are encrypted at rest. - Data can be deleted immediately when all participants leave a room. - Partners can also configure retention periods for automatic deletion of older data. ## Modular Architecture MessagingHub is not a monolithic chat server. Its components have clearly separated responsibilities and communicate through loosely coupled events. - **`connection-manager`** - Manages WebSocket connections and validates connection tokens. - Tracks user connection status. - Helps identify active chatbot scenario connections during `SOFT STOP` processing. - **`chat-app`** - Implements core chat logic, including message delivery, room creation, state transitions, and read status. - Exposes functionality as commands that can be combined for different chat types. - **`message-router`** - Determines where recipients are connected. - Routes messages from the chat server to the appropriate connection-management component. - **`notification-app`** - Sends push notifications when recipients are offline or the application is in the background. - Uses partner-provided `pushToken` values and room-level notification settings. - **`admin-hub`** - Manages chatbot scenario editing and deployment. - Handles agent accounts, roles, service contexts, events, webhooks, monitoring, and statistics. ## Command-Based Chat Flows - Chat behavior is modeled as composable commands. - Common commands provide functionality shared across chat types. - Chatbot and inquiry-chat features add more specialized commands. - This “building block” approach allows business requirements to be assembled without creating a separate chat implementation for every domain. ## Data Model MessagingHub separates operational data from core chat data: - **`chat` database:** Stores users, rooms, participants, metadata, and messages. - **`chat_operation` database:** Stores operational and administrative information. Important entities include: - `chat_user`: Uniquely identifies users by `client_id`. - `chat_room`: Represents rooms and enforces room uniqueness at the schema level. - `chat_member`: Connects users to rooms. - `chat_room_meta`: Stores participant-specific state, including read position, push settings, input restrictions, and room status. - `chat_log`: Stores encrypted messages in a one-to-many relationship with rooms. - `prev_chat_log_id` preserves message ordering. - Room-level first and last message IDs, together with participant read positions, support unread-count calculation. - Partner metadata such as `system_data`, `search_data`, `user_details`, and `descriptions` is stored as JSON. MessagingHub preserves and forwards it without interpreting its domain meaning. - Scheduling, event, and webhook history are tracked through tables such as `chat_schedule`, `chat_event_record`, and `webhook_event_record`. - `service_context`, `chat_event`, and `webhook` configure allowed role relationships, event-message policies, and webhook behavior. ## Chatbot Scenario Management ### Flexible Scenario Structure - Administrators manage multiple chatbot scenarios through an editing tool. - Scenarios define messages, selectable options, and answers. - Webhooks can dynamically generate response content. - The hierarchical data model supports a broad range of chatbot flows. ### Version Deployment and `SOFT STOP` Chatbot scenarios transition through: `WAIT → SERVICE → SOFT STOP → DISABLE` - A newly deployed scenario becomes `SERVICE`. - The previous scenario moves to `SOFT STOP`. - Existing users can finish conversations using the previous version. - New users are directed to the latest scenario. - A scheduler periodically checks whether any users still have active connections to the old scenario. - Connection information is collected from connection-management servers and stored in a shared resource. - Once no active users remain, the old scenario is disabled and the scheduler stops. - This provides backward compatibility without disrupting users during deployment. ## Inquiry Chat Metadata and Lifecycle ### Partner-Defined Metadata Inquiry chat allows partner domains to provide information that helps agents handle cases effectively: - Search data for finding conversations - User details shown to agents - Custom display data - Event data for surveys or webhooks - Basic consultation descriptions - Room settings such as room names and push-notification titles - Tracking data for identifying and mapping rooms in partner systems ### Room Lifecycle Inquiry rooms generally move through: `PENDING → SERVICE → DISABLE → BLOCK` - `PENDING` represents the period while the user waits for an agent match. - `SERVICE` is the active consultation period. - `DISABLE` indicates that the consultation has ended. - `BLOCK` prevents further messaging after closure. MessagingHub’s overall approach is to keep the platform’s responsibilities narrow and reusable while allowing partner domains to own authentication, user meaning, and business-specific metadata. For organizations supporting multiple chat scenarios, a policy-driven, command-based platform with separated components and explicit data ownership can significantly reduce duplication and integration risk.
Read original(opens in new tab)