CP Pairing System Architecture: From Relationship Binding to Real-Time Interaction

This article documents the complete technical evolution of a production-grade CP (Character Pairing) system from prototype to maturity. A CP system is a 1-to-1 exclusive social relationship management system widely used in live streaming and social platforms. The article discusses system design, architecture evolution, performance optimization, and technical decision-making.

Tech Stack: Spring Boot 3.2, MySQL 8.0, Redis 7.0, Kafka 3.6, WebRTC, SVGA Effects Engine

1. CP System Technical Overview

1.1 System Definition and Technical Characteristics

CP = Character Pairing, a 1-to-1 exclusive social relationship system.

A CP system is a combination of social relationship network + interaction engine + real-time communication system, with technical complexity far exceeding ordinary friend relationship systems.

Technical differences between Friend and CP relationships:

Core Technical Comparison:

• Quantity constraint: Friends = unlimited; CP = 1-to-1 exclusive (core constraint)

• Establishment mechanism: Friends = one-way/two-way; CP = mutual confirmation

• Data consistency: Friends = low requirements; CP = strong consistency requirements

• Technical difficulty: Friends = simple; CP = high (requires state machines, transactions, distributed locks)

Exclusivity is the biggest technical challenge: A user can only have 1 CP at a time. Technical implementation points:

• Must ensure data consistency (no multiple CPs per person)

• Requires complex state machines (pending, confirmed, dissolved, cooldown)

• Distributed locks needed in high-concurrency scenarios

The initial design used MySQL INSERT operations directly, which encountered concurrency issues in production: one user received 2 invitations simultaneously, both succeeded, resulting in data inconsistency.

1.2 Core Functional Modules of CP System

A complete CP system contains the following technical modules:

CP System Architecture
├── CP Relationship Management
│   ├── Invite/Accept/Reject/Dissolve
│   ├── State Machine Management
│   └── Exclusivity Verification
├── Intelligent Matching & Recommendations
│   ├── Collaborative Filtering Algorithm
│   ├── Content Similarity Calculation
│   └── Activity Scoring
├── Intimacy System
│   ├── Interaction Behavior Scoring
│   ├── Level System (1-10 levels)
│   └── Real-time Cache Sync
├── CP Interactive Features
│   ├── Dual Video Calls
│   ├── CP Exclusive Effect Rendering
│   ├── Real-time Interaction Sync
│   └── Task Progress Tracking
├── CP Leaderboards
│   ├── Real-time Ranking Calculation
│   ├── Multi-dimensional Sorting
│   └── High-performance Queries
└── Monitoring & Alerts
    ├── Relationship Consistency Checks
    ├── Performance Metrics Monitoring
    └── System Anomaly Alerts

2. Database Design: Evolution from Simple to Complex

2.1 V1 Version: Single Table Design Issues

The initial design used a single table storage approach:

-- V1 version: Simple but problematic
CREATE TABLE cp_relationships_v1 (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id_a BIGINT NOT NULL,
    user_id_b BIGINT NOT NULL,
    status TINYINT NOT NULL COMMENT '1=pending 2=confirmed 3=dissolved',
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,

    KEY idx_user_a (user_id_a),
    KEY idx_user_b (user_id_b)
) ENGINE=InnoDB;

Issues exposed in production:

Issue 1: Data Consistency

• Symptom: Concurrent invitations resulted in one person having multiple CPs

• Cause: Only regular indexes were used, no unique constraints

• Impact: Data consistency compromised

Issue 2: Query Performance

• Symptom: Query interface timed out at QPS 1000

• Cause: Query condition WHERE user_id_a = ? OR user_id_b = ? invalidated index

• Impact: P99 latency increased from 80ms to 2.3 seconds

Issue 3: Historical Data Loss

• Symptom: Unable to query history after CP dissolution

• Cause: Records were directly deleted using DELETE

• Impact: Historical query functionality impossible

2.2 V2 Version: Adding Constraints and Indexes

Addressing V1 issues, the database structure was redesigned:

-- V2 version: Added unique constraints and state management
CREATE TABLE cp_relationships (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id_a BIGINT NOT NULL COMMENT 'User A ID (initiator)',
    user_id_b BIGINT NOT NULL COMMENT 'User B ID (acceptor)',
    status TINYINT NOT NULL COMMENT '1=pending 2=confirmed 3=dissolved 4=cooldown',
    intimacy_value INT DEFAULT 0 COMMENT 'CP intimacy value',
    level TINYINT DEFAULT 1 COMMENT 'CP level 1-10',
    established_at DATETIME COMMENT 'CP confirmation time',
    dissolved_at DATETIME COMMENT 'CP dissolution time',
    cooldown_until DATETIME COMMENT 'Cooldown end time',
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

    -- Core constraint: ensure one person has only one active CP
    UNIQUE KEY uk_user_a (user_id_a, status),
    UNIQUE KEY uk_user_b (user_id_b, status),

    -- Query optimization indexes
    KEY idx_intimacy (intimacy_value DESC), -- Leaderboard queries
    KEY idx_established (established_at), -- Time range statistics
    KEY idx_users (user_id_a, user_id_b) -- Bidirectional queries
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='CP relationship table';

Key Technical Improvements:

1. Unique Constraint for Data Consistency

UNIQUE KEY uk_user_a (user_id_a, status)

This constraint ensures the (user_id_a, status) combination is unique.

Technical note: MySQL's unique index doesn't work for NULL values. Therefore, status is set to NOT NULL, and CP dissolution updates status rather than deleting records.

2. Cooldown Mechanism

Technical solution to prevent frequent relationship creation/dissolution:

• 7-day cooldown period after CP dissolution

• cooldown_until field records cooldown end time

• Check cooldown status when initiating invitations

3. Data Redundancy Optimization

Storing intimacy data redundantly in the relationship table avoids frequent JOINs, improving query performance by 60%.

2.3 V3 Version: Adding Interaction Records Table

To support interaction history tracking, a detailed records table was added:

-- CP interaction records table
CREATE TABLE cp_interactions (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    cp_id BIGINT NOT NULL COMMENT 'CP relationship ID',
    interaction_type VARCHAR(32) NOT NULL COMMENT 'Interaction type: video_call, gift, task, chat',
    initiator_id BIGINT NOT NULL COMMENT 'Initiator ID',
    receiver_id BIGINT COMMENT 'Receiver ID',
    intimacy_gain INT NOT NULL COMMENT 'Intimacy gained',
    metadata JSON COMMENT 'Interaction details',
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,

    -- Query optimization indexes
    KEY idx_cp_time (cp_id, created_at),
    KEY idx_type_time (interaction_type, created_at),
    KEY idx_initiator (initiator_id, created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='CP interaction records';

JSON Field Usage Strategy:

Different interaction types have varying detail fields:

• Video call: {"duration_seconds": 1200, "quality": "HD"}

• Gift interaction: {"gift_id": 10086, "gift_name": "Virtual Gift", "quantity": 1}

• Task completion: {"task_id": 5, "task_name": "10 calls", "reward": 1000}

JSON fields store unstructured data flexibly, but note: JSON fields cannot be indexed. Therefore, frequently-queried fields are extracted as separate columns.

2.4 Performance Comparison Data

Performance Comparison Across Versions:

• Query CP relationship: V1: 2.3s → V2: 80ms → V3: 65ms

• Leaderboard TOP100: V1: timeout → V2: 420ms → V3: 180ms

• Insert interaction record: V3: 15ms

• Query interaction history: V3: 95ms

• Concurrent invitations (1000 QPS): V1: data errors → V2/V3: normal

Core Database Design Lessons:

1. Unique constraints are more reliable than application-layer validation

2. Appropriate redundancy beats frequent JOINs (directly duplicate high-frequency query fields)

3. JSON fields need regular columns for indexing

4. Soft delete is better than hard delete (data is traceable)

3. CP Matching & Recommendations: Algorithm Optimization Journey

3.1 V1 Version: Random Recommendations

The initial version used a simple random recommendation algorithm:

// V1 version: Random recommendations
public List<User> recommendCP(Long userId) {
    return userRepository.findAll().stream()
        .filter(u -> !u.getId().equals(userId))
        .filter(u -> !u.hasCP())
        .limit(20)
        .collect(Collectors.toList());
}

Algorithm characteristic: Randomly select from all users without CPs

Issues with this approach:

• Match accuracy only 12%

• Many inactive accounts recommended

• Unable to consider user feature compatibility

3.2 V2 Version: Tag-Based Content Matching

Introduced tag system, using Jaccard similarity to calculate match scores.

Technical Issues:

Issue 1: Cold Start

• New users lack tag data

• Can only recommend popular users, causing uneven traffic distribution

Issue 2: Activity Not Considered

• High-match users may be long-term inactive

• Recommendation quality affected

Issue 3: Lack of Complementarity

• Similar user combinations have less interaction value than complementary users

• Time overlap not considered

Performance data:

• Match accuracy increased from 12% to 28%

• Inactive account match rate 23%

3.3 V3 Version: Hybrid Recommendation Algorithm

Adopted a multi-dimensional weighted hybrid recommendation algorithm:

Algorithm Architecture:

Recommendation Score = Collaborative Filtering(40%) + Content Similarity(30%) + Activity(20%) + Complementarity(10%)

Core technical components:

• Collaborative Filtering: Calculate candidate set based on user behavior similarity

• Activity Scoring: Evaluate user activity status based on recent 7-day behavior data

• Complementarity Scoring: Consider skill complementarity, time complementarity, attribute complementarity

3.4 Performance Optimization Solutions

Issue 1: High Collaborative Filtering Computation Latency

Similarity calculation for 10,000 users took 5 seconds. Optimization solutions:

• Parallel computation: Use thread pool for parallel processing

• Redis pre-computation: Periodically pre-compute user similarity matrix

• Post-optimization latency: 5s → 300ms

Issue 2: Feature Vector Storage Performance

User behavior feature vector storage optimization:

• Migrated from MySQL to Redis Set

• Query latency: 200ms → 15ms

3.5 Algorithm Performance Comparison

Matching Algorithm Performance Comparison:

• Match accuracy: V1: 12% → V2: 28% → V3: 78%

• Inactive account match rate: V2: 23% → V3: 2%

• Recommendation API P99 latency: V1: 3.2s → V2: 850ms → V3: 320ms

• 7-day dissolution rate: V1: 68% → V2: 42% → V3: 15%

Core Technical Lessons:

1. Multi-dimensional scoring outperforms single dimension

2. Activity is a key filtering criterion

3. Complementarity improves match quality

4. Collaborative filtering requires performance optimization

4. CP Interactive Features: Real-time Communication Architecture

4.1 Dual Video Calls: WebRTC Architecture

Technical requirement: Implement real-time video calling between both parties with display in respective rooms.

Technical Selection Comparison:

Option 1: Third-party SDK

• Pros: Easy integration, stable quality

• Cons: High cost

Option 2: Self-built WebRTC

• Pros: Low cost (server costs only)

• Cons: High technical complexity

• Final choice: Self-built solution

Architecture Design:

┌─────────────┐         ┌─────────────┐
│  Client A   │         │  Client B   │
└──────┬──────┘         └──────┬──────┘
       │ WebSocket signaling    │
       ├─────────┐       ┌────────┤
       │         ↓       ↓        │
       │    ┌──────────────┐     │
       │    │ Signaling    │     │
       │    │ Server       │     │
       │    │(Spring Boot) │     │
       │    └──────────────┘     │
       │                          │
       │ WebRTC media stream      │
       └────────┐       ┌─────────┘
                ↓       ↓
          ┌──────────────────┐
          │  SFU Media       │
          │  Server          │
          │(Janus Gateway)   │
          └──────────────────┘

Core technical points:

• Use distributed locks to ensure only one room per CP

• JWT Token controls access permissions (30-minute validity)

• Calculate duration and update system state after call ends

Performance Optimization:

Issue 1: WebRTC Handshake Latency

Solution: Specify domestic STUN server, handshake time reduced from 3s to 800ms

Issue 2: Audio/Video Synchronization

Solution: Reduce buffer latency, sync error reduced from 500ms to under 100ms

Issue 3: Weak Network Environment Adaptation

Solution: Client adaptive bitrate adjustment

4.2 CP Exclusive Effects: Dual-Client Synchronized Rendering

Technical requirement: Effects trigger synchronously on both clients with latency <200ms.

Technical Challenges:

1. Real-time: Latency not exceeding 200ms

2. Dual-client sync: Trigger time difference <50ms

3. Resource loading: SVGA files need preloading

Architecture Design:

Effect Trigger → Effect Service → Kafka Event Bus → Distribute to Both Clients
                                      ↓
                               Effect Handler
                               ├─ Client A (WebSocket push)
                               └─ Client B (WebSocket push)
                                      ↓
                               Client Receives → CDN Preload Resources → SVGA Render

Effect System Performance Data:

• Effect latency: 2.3s → 180ms

• Resource load time: 3.1s → 80ms (with preload)

• Dual-client sync error: 500ms → <50ms

• WebSocket push success rate: 94% → 99.2%

Core Technical Lessons:

1. Preloading mechanism is key

2. Kafka for traffic peak shaving

3. Parallel pushing reduces latency

4. eventId implements idempotency

5. Intimacy System: Real-time Calculation and Cache Synchronization

5.1 Intimacy Calculation Rules

Technical requirement: Accumulate intimacy through interaction behaviors, support level system.

Scoring Rules Design:

Scoring Rules by Interaction Type:

• Video call: 10 points/minute — Daily cap: 300 points

• Exclusive interaction: Weight coefficient ÷ 10 — Daily cap: 5,000 points

• Regular interaction: Weight coefficient ÷ 20 — Daily cap: 1,000 points

• Task completion: Task configuration — No cap

• Text interaction: 1 point/message — Daily cap: 100 points

• Dual online: 20 points/minute — Daily cap: 600 points

Technical Reason for Daily Caps:

Prevent scripted point farming attacks. Initially no caps were set, resulting in cases of 100,000 points farmed in a single day.

5.2 Intimacy Level System

Designed 10-level system, from "First Meeting" (Level 1, 0-999) to "Eternal" (Level 10, 1M+).

Level Design Strategy:

1. First 3 levels low threshold: Quick feedback

2. Middle gradient reasonable: Each level requires 2-3 weeks

3. Top level high difficulty: Level 10 requires 6+ months

5.3 Real-time Calculation Architecture: MySQL + Redis Dual-Write

Technical Challenges:

1. High-concurrency writes: Popular CPs have 100+ updates per minute

2. Real-time queries: Queries cannot have delays

3. Data consistency: MySQL and Redis must stay consistent

First Version: Direct MySQL Writes

Issues:

• Connection pool exhausted at QPS 3000

• UPDATE operations cause severe lock contention

• P99 latency reached 800ms

Second Version: Redis Cache + Async MySQL Flush

Issues:

• Redis crash causes data loss

• Async flush timing uncertain

• Multi-threaded flush causes data overwrites

Third Version: Dual-Write + Scheduled Sync (Final Solution)

Architecture design:

1. Immediately write to Redis (real-time queries)

2. Record increment to Redis queue

3. Scheduled task batch flushes to MySQL every 10 seconds

Performance Data Comparison:

• Write QPS: V1: 3,000 (limit) → V2: 50,000+ → V3: 50,000+

• Write latency: V1: 80ms → V2: 5ms → V3: 6ms

• Query latency: V1: 50ms → V2: 2ms → V3: 2ms

• Data consistency: V1: Strong → V2: Eventual → V3: Near real-time (within 10s)

• Disaster recovery: V1: Poor → V2: Poor → V3: Good

Core Technical Lessons:

1. Redis for real-time read/write, MySQL for persistence

2. Scheduled sync more stable than real-time sync

3. Must implement reconciliation mechanism

4. Degradation plan required

6. CP Task System: Event-Driven Architecture

6.1 Task System Design

Technical requirement: Guide interaction behaviors through tasks, grant rewards upon completion.

Task Types:

• Daily tasks: "Today's Call" (call at least once, reward: 50 points)

• Weekly tasks: "Intimate Time" (60 minutes of calls this week, reward: 500 points)

• Achievement tasks: "100-Day CP" (maintain relationship for 100 days, reward: 5,000 points)

6.2 Event-Driven Task Progress Updates

Architecture Design:

Business Event → Kafka → Task Handler → Update Progress → Check Completion → Grant Rewards

Advantages of Event-Driven:

Initially used synchronous calls; task system failures would affect main business flow. After switching to event-driven:

• Decoupling: Task system runs independently

• Performance: Async processing doesn't block

• Extensibility: Adding new task types doesn't require business code changes

7. CP Leaderboards: Redis ZSet Application

7.1 Leaderboard Types

Technical requirement: Implement multi-dimensional real-time leaderboards.

Leaderboard Types:

• Intimacy leaderboard: Sort by CP intimacy value — Update: real-time

• Weekly leaderboard: Sort by weekly data — Update: real-time

• Monthly leaderboard: Sort by monthly data — Update: hourly

• Popularity leaderboard: Sort by composite metrics — Update: hourly

• Newcomer leaderboard: CPs established within 7 days — Update: real-time

7.2 Technical Choice: Redis ZSet

Solution Comparison:

• MySQL ORDER BY: Pros: Simple — Cons: Slow — Use case: Small data

• Elasticsearch: Pros: Powerful — Cons: Complex — Use case: Complex search

• Redis ZSet: Pros: Extremely fast, simple — Cons: Memory usage — Use case: Leaderboards

Redis ZSet Performance Test:

# 1 million CPs, query TOP100 leaderboard
ZREVRANGE cp:intimacy:rank 0 99 WITHSCORES

# Time taken: 3ms (MySQL same query needs 800ms)

7.3 Core Implementation

Core features:

• Update ranking: Called on each data change

• Get TOP100: Returns within 3ms

• Get ranking: Query specific CP's rank position

• Periodic reset: Weekly leaderboard resets Monday midnight

7.4 Performance Optimization: Cache Warming and Degradation

Issue 1: Inaccurate Data During Cold Start

Solution: Warm up on application startup, load data from MySQL and batch write to Redis ZSet.

Issue 2: High Hot Key Access Volume

Solution: Local cache (Caffeine) + scheduled refresh, 10-second expiry.

Optimization results:

• Redis QPS dropped from 50,000 to 500 (100x reduction)

• API response time dropped from 3ms to 0.5ms

• Application memory increased by ~10MB

8. Monitoring and Alerts: Production Environment Safeguards

8.1 Core Monitoring Metrics

Business metrics:

Business Monitoring Metrics:

• New CPs per hour: Alert threshold: <10

• CP success rate: Alert threshold: <30%

• CP dissolution rate: Alert threshold: >20% daily

• Intimacy daily growth: Alert threshold: <50

• Video calls per hour: Alert threshold: <100

Technical metrics:

Technical Monitoring Metrics:

• API response time: Tool: Prometheus — Alert: P99 >500ms

• Redis memory usage: Tool: Redis INFO — Alert: >80%

• MySQL connections: Tool: SHOW PROCESSLIST — Alert: >80%

• Kafka consumer lag: Tool: Kafka Lag — Alert: >10,000

• WebSocket online count: Tool: Custom collection — Alert: 50% drop

8.2 Data Consistency Checks

Scheduled inspection script runs daily at 3am:

1. Check: One person cannot have multiple CPs simultaneously

2. Check: CP relationship must be symmetric

3. Check: Redis and MySQL data differences

4. Check: Leaderboard data consistency

5. Check: Orphan data cleanup

9. Technical Decision Review

After a complete development and operation cycle, reviewing key technical implementation decisions.

9.1 Database Design

Successful Decisions:

• ✅ Unique indexes ensure one CP per person

• ✅ Soft delete retains historical data

• ✅ Intimacy redundancy avoids JOINs

Improvement Directions:

• Consider using separate attribute table instead of JSON (improve query performance)

• Add version field for optimistic locking

9.2 Matching Algorithm

Successful Decisions:

• ✅ Hybrid recommendation algorithm

• ✅ Activity filtering

Improvement Directions:

• Introduce A/B testing framework

• Consider machine learning models

• Implement negative feedback mechanism

9.3 Real-time Interactions

Successful Decisions:

• ✅ Self-built WebRTC

• ✅ Kafka event-driven

Improvement Directions:

• Introduce distributed locks from initial design

• Implement resource preloading mechanism

• Perfect heartbeat and reconnection mechanisms

9.4 Performance Optimization

High-Value Optimizations:

1. Leaderboard local cache: 100x QPS reduction

2. Intimacy batch MySQL flush: 10x performance improvement

3. Collaborative filtering parallel computation: latency from 5s to 300ms

10. Summary

10.1 Tech Stack Summary

Backend:

• Spring Boot 3.2 + MyBatis-Plus

• MySQL 8.0 (sharding: modulo by CP ID)

• Redis 7.0 Cluster (5 masters, 5 replicas)

• Kafka 3.6 (3 brokers)

• Janus WebRTC Gateway

Frontend:

• iOS: Swift + WebRTC SDK

• Android: Kotlin + WebRTC SDK

• Web: Vue 3 + WebRTC.js

Infrastructure:

• Kubernetes (container orchestration)

• Prometheus + Grafana (monitoring)

• ELK (log analysis)

• Jenkins (CI/CD)

10.2 Core Technical Lessons

1. System Design

• Core of CP system is 1-to-1 exclusivity constraint

• Unique indexes > application-layer validation

• Event-driven architecture enables decoupling

• Distributed locks are essential

2. Performance Optimization

• Cache layering: Local cache > Redis > MySQL

• Batch operations > single operations

• Async > sync

• Preload > real-time load

3. Operations Assurance

• Monitoring covers business and technical metrics

• Real-time alerts for core metrics

• Regular data reconciliation

• Complete degradation plans

4. Technology Selection

• Simple requirements use simple technology

• Complex requirements use appropriate technology

• Don't over-design

• Stability > cutting-edge

Appendix: Related Resources

Open Source Projects:

• Janus WebRTC Gateway

• SVGA Player

Technical Documentation:

• Redis ZSet Performance Optimization

• WebRTC Best Practices

• Kafka Consumer Best Practices