Designing a Scalable CRM User Reach Module: Architecture, Performance & Monitoring

A year after the departure of a technical expert, the author shares a comprehensive CRM user reach module design template, covering project overview, revision history, requirements, design goals, architecture, detailed design, risk assessment, testing, and deployment.

1. Project Overview

Project Name

CRM System

Project Leader

三分恶

Module Name

用户触达模块

Module Leader

三分恶

First part describes the project or module overview; it is not critical but required.

2. Revision Record

Version

Reviser

Revision Content

Revision Date

V1.0

三分恶

Creation

2022-12-23

Design evolves with business changes; each version should be recorded.

3. Requirement / Background

Product document: xxxx

To achieve fine‑grained user operation, the system sends notification messages through multiple channels.

4. Design Goals

Design goals are split into two parts: Functionality: break down product requirements into CRUD operations. Design Metrics: set performance and availability targets such as average response ≤200 ms, single‑machine QPS ≈ 1000, 99.9% availability, etc.

4.1 Implemented Functions

Multi‑channel message push (internal and external):

Internal: site messages, pop‑ups.

External: email, SMS, push, WeChat, …

Reach task management:

Support scheduled/delayed sending.

Support trigger‑based sending.

Support user segmentation.

4.2 Design Metrics

Performance:

Million‑level messages per minute.

Interface xx: single‑machine 1000 concurrent, 95% response ≤200 ms.

Availability:

Reach module 99.9% uptime.

Message delivery success rate >80%.

Scalability:

Strategy pattern + configuration for adding new channels with minimal code.

Rule engine for channel selection without redeployment.

Compatibility:

Interface xxx forward‑compatible with app version 1.9.0; older versions require forced upgrade.

Observability:

Integrate Prometheus & Grafana for service monitoring (CPU, memory, JVM, QPS, latency).

Business monitoring via event tracking to view reach success rates by device and channel.

Alerting:

Use PrometheusAlert for service and business alerts, notifying via Feishu, phone, etc.

5. High‑Level Design

5.1 Design Idea

Handle millions of messages per minute; require high‑performance DB and traffic‑shaping.

Scheduled/delayed messages via high‑throughput message queues (RocketMQ, Kafka).

5.2 Technical Selection

Storage: TiDB

Cache: Redis

Message Queue: RocketMQ (business), Kafka (tracking)

Service Registry & Config: Nacos

RPC: Dubbo

Gateway: Gateway

Push Channel: Self‑built

5.3 Business Architecture

5.4 Technical Architecture

5.5 System Environment

JDK 11

Deployment: k8s + Containerd, pod 8 CPU + 4 GB, 32 pods total.

Database:

Business data: TiDB 64 CPU + 128 GB.

Offline data: HBase …

6. Detailed Design

6.1 Process Design

Push flow diagram (illustrated in the following image).

6.2 Algorithm Design

Channel sharding: weighted random algorithm to split a message type across multiple channels.

6.3 Data Model Design

Field

Description

Data Type

id

Primary key

bigint

task_no

Task number

bigint

comment

Description

varchar

6.4 Interface Design

Interface Name

Add Payment Task

Documentation URL

https://yapi.com/xxx

Input Parameter Description

comment: task description

6.5 Exception Handling

Unified handling of unknown system exceptions, returning "Network Error".

Asynchronous tracking events should not affect core functionality.

7. Risk Assessment

7.1 Known Risks

High load on data services may cause crashes (user segmentation, profiling).

Message queue backlog leading to delayed delivery.

High QPS causing database CPU spikes.

7.2 Potential Risks

Delayed scenario messages may affect transaction flows and reduce conversion rates.

8. Test Recommendations

8.1 Functional Testing

Feature

Test Steps

Expected Result

Scheduled Message Sending

Create a scheduled message

Message is sent at the scheduled time

8.2 Performance Testing

Stress test interface xxx, target single‑machine QPS ≈ 1000.

9. Deployment Preparation

Ops set up environment.

Data initialization.

Add configuration.

Create message queues.

Deploy dependent services.

Launch the service.

10. Review and Comments

Review Comment

Author

Date

Resolution

Resolver

Resolution Date

Interface xxx needs compatibility fix; change field from object to list.

老六

2023-01-01

Modify field type

老三

2023-01-01

The design document must go through review meetings; issues are recorded, resolved, and re‑reviewed until approval before development starts.