How to Design a Scalable CRM User Reach Module: Architecture, Metrics, and Best Practices

Project Overview

The document describes a CRM system’s user‑reach module, aimed at fine‑grained user operations by sending notifications through multiple channels (in‑app, push, email, SMS, WeChat, etc.). It records basic project information such as name, owner, and module lead.

Revision History

Version V1.0 was created on 2026‑03‑01 by the module owner.

Design Goals

Functional Goals : Break down product requirements into CRUD‑style features, including multi‑channel message delivery and task management.

Design Metrics : Define performance targets (e.g., average response ≤200 ms, single‑machine QPS ≈ 1000), availability (99.9% uptime, >80% message success), scalability (strategy‑pattern configuration for new channels), compatibility, observability, and alerting.

Functional Design (Section 4.1)

Message delivery supports two major groups:

In‑app: internal messages, pop‑ups.

Out‑of‑app: email, SMS, push, WeChat, etc.

Task management includes scheduled/delayed sending, trigger‑based sending, and user‑segmented delivery.

Algorithmic note: channel weighting uses a weighted random algorithm for proportional distribution.

Design Metrics (Section 4.2)

Performance : support million‑level messages per minute; interface xx target 1000 concurrent requests with 95% latency ≤200 ms.

Availability : 99.9% service uptime; >80% message delivery success.

Scalability : add new channels via strategy pattern and configuration; rule engine enables channel changes without redeployment.

Compatibility : forward‑compatible API for app version 1.9.0, older versions require forced upgrade.

Observability : integrate Prometheus and Grafana for service and business metrics, including CPU, memory, QPS, latency, and user‑reach success rates.

Alerting : PrometheusAlert triggers tiered alerts sent via Feishu, phone, etc., covering both service‑level (resource exhaustion) and business‑level (low delivery rate) issues.

Architecture Overview (Section 5)

Key technology choices:

Database: TiDB for transactional data, HBase for offline data.

Cache: Redis.

Message queues: RocketMQ for business messages, Kafka for telemetry.

Service registry & configuration: Nacos.

RPC framework: Dubbo.

Gateway: Spring Cloud Gateway.

Push channel: custom implementation.

Detailed Design (Section 6)

Process Flow

The push notification flow is illustrated in the diagram below.

Algorithm Design

Channel sharding: weighted random selection to distribute a single message type across multiple channels.

Data Model

Example table crm_user_touch_task stores task metadata (id BIGINT primary key, task_no BIGINT, comment VARCHAR, etc.).

API Design

Key endpoint: /addPaymentTask (documented in YAPI at https://yapi.com/xxx). Request includes a comment field describing the task; response structure is defined in the same spec.

Exception Handling

Unified handling of unknown errors, returning a generic “Network Error”.

Asynchronous telemetry reporting to avoid impacting core functionality.

Risk Assessment (Section 7)

Potential data‑service overload causing user‑group or profiling failures.

Message‑queue backlog leading to delayed delivery.

High QPS may cause database CPU spikes.

Latency in time‑critical messages could reduce conversion rates.

Testing Recommendations (Section 8)

Functional Tests

Example: create a scheduled message and verify it is sent at the expected time.

Performance Tests

Stress test interface xx with an expected single‑machine QPS of 1000.

Deployment Checklist (Section 9)

Provision environment (k8s + Containerd, 8‑core CPU + 4 GB RAM per pod, 32 pods total).

Initialize data stores (TiDB, HBase, Redis).

Configure services (Nacos, Dubbo, Gateway).

Create required message‑queue topics.

Deploy dependent services.

Roll out the user‑reach service.

Review & Feedback (Section 10)

Review comments are recorded with proposer, date, resolution, and assignee. Example: change a field type from object to list for compatibility, resolved by the module lead.

Design documents are living artifacts; they must be reviewed, updated, and aligned with product, operations, and testing teams before implementation.