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.