Backend Development 7 min read

Design and Implementation of a Flexible Fatigue Control Mechanism for Real-Time User Reach

The article presents a flexible fatigue‑control mechanism for Omega’s real‑time user‑reach system that replaces fixed windows with dynamic, user‑scene‑business dimensions and a minimum interval, eliminating duplicate daily messages, dispersing delivery times, maintaining stable 6000‑QPS performance, and paving the way for reusable components and recommendation integration.

Xianyu Technology
Xianyu Technology
Xianyu Technology
Design and Implementation of a Flexible Fatigue Control Mechanism for Real-Time User Reach

Omega's real-time reach system integrates behavior collection, CEP rule center, and user reach center to push content based on user actions. While real-time delivery improves relevance, excessive notifications can damage user experience, making user-friendly reach a critical challenge.

This article examines fatigue control strategies, focusing on how to design flexible and fine-grained mechanisms that reduce user disturbance.

Early implementations revealed two main problems: users sometimes received identical messages on consecutive days, and in scenarios allowing multiple reaches per cycle, the delivery times were overly concentrated, both leading to negative user feedback.

The original Fatigue Mechanism 1.0 relied on fixed fatigue windows defined by a constant start point. This caused adjacent‑day duplicate deliveries and failed to handle dynamic period changes, resulting in clustered reach events.

Fatigue Mechanism 2.0 introduces three control dimensions—user, scene, and business—and adopts a dynamic window start time based on the first non‑fatigued reach. Fatigue keys are now derived from user and business identifiers, preventing data loss during period adjustments. Additionally, a minimum interval between successive reaches is enforced to disperse delivery times.

After deploying version 2.0 across more than thirty business scenarios, analysis showed: no duplicate deliveries on consecutive days, stable behavior during dynamic period changes, and a more dispersed reach distribution. The system now handles peak QPS of around 6000 with stable performance.

Future plans include packaging the fatigue service as a reusable component for other services and feeding fatigue‑related data back to recommendation algorithms to further optimize reach strategies.

backend designfatigue controlReal-time MessagingSystem Architectureuser experience
Xianyu Technology
Written by

Xianyu Technology

Official account of the Xianyu technology team

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.