How BeReal Dominates Using Time-Synchronized Global Push Notifications

Introduction: The Synchronous Traffic Storm

Most mobile applications distribute user traffic throughout the day, allowing server clusters to auto-scale gradually. However, BeReal operates on a radically different model.

Once per day, at a randomized time, the application dispatches a synchronized push notification to tens of millions of users globally. Within a two-minute window, a massive percentage of these users open the app simultaneously to capture and post their daily photo.

This design creates a sudden, extreme surge in API traffic, turning the application's infrastructure into a real-world stress test. Handling this requires a push notification system that can dispatch millions of alerts in seconds, coupled with a server architecture designed to absorb immense traffic spikes without crashing.

Massive Push Dispatch Architecture

Delivering notifications to millions of users in under a minute is a difficult task. Simply looping through database records and sending API requests to Google's FCM (Firebase Cloud Messaging) and Apple's APNs (Apple Push Notification service) would take hours. To scale, the notification engine must utilize parallel worker pools and horizontal queue scaling.

BeReal's backend divides the global user base into regional cohorts based on time zones. When the trigger event fires, the push service serializes notification payloads and distributes them across high-performance message brokers.

Workers consume these queues in parallel, opening persistent HTTP/2 connection multiplexes to FCM and APNs. By batching push tokens and optimizing connection reuse, the system can dispatch millions of push requests per second, ensuring users receive the prompt simultaneously.

Graceful Degradation and Traffic Staggering

While sending the notifications is a massive challenge, surviving the resulting wave of API requests is even harder. If every client queried the database immediately upon opening the app, the system would collapse. BeReal employs several architectural techniques to manage this traffic storm:

• Client-Side Jitter: The client application introduces a small, randomized delay (jitter) of several seconds before firing non-critical API requests, preventing a massive, synchronized peak of requests from hitting the server at the exact same millisecond.
• Read-Heavy Caching: All feed data, profiles, and configuration parameters are cached aggressively using geo-distributed in-memory stores. The primary transactional database is kept isolated from read traffic.
• Degraded Features: If the API layer experiences heavy queue times, non-essential operations (such as loading comments or historical memories) are automatically disabled, prioritizing the upload and rendering of the primary daily post.
• Optimistic UI Writes: The user interface is designed to assume success. When a user uploads their post, the app displays the content immediately, handling the background server write and retries asynchronously.

These strategies allow the system to maintain high availability and responsiveness under extreme load, protecting core transactional database instances from saturation.

CDN Pre-Warming and Edge Optimization

When millions of users open their apps, they also request the media files of their friends. Loading these high-resolution images directly from primary storage is impossible under peak load. BeReal relies on globally distributed Content Delivery Networks (CDNs) with aggressive edge caching policies.

By routing all media requests through edge servers, the platform offloads file delivery entirely. When a user uploads a new post, the image is immediately replicated to edge caches near their friend circles. When the push notification lands, the vast majority of image requests are served directly from edge memory, ensuring fast load times and preserving core server bandwidth.

Mitigating Instantaneous Peak Loads at the Edge with Bramsley

Surviving massive, synchronized traffic spikes requires an infrastructure that can absorb load before it reaches backend servers. Bramsley designs tailored edge solutions to intercept and optimize traffic spikes.