User System and Multi-Device Sync Architecture for Content Platforms

1. Introduction: Why the User System Is the Foundation of a Content Platform

When users open a video, comic, or live sports platform, the first thing they encounter is usually not the content itself but a full set of account capabilities: registration and login, membership benefits, cross-device playback progress sync, favorites, notifications, and interactive features such as comments and bullet chat. These features look separate, but they all share the same underlying data: user identity. The quality of the user system design directly determines outcomes at three levels:

1. Experience: If a user watches half an episode on a phone, can playback resume precisely on a tablet or TV?
2. Business: Can membership entitlements reliably and accurately control access to paid content?
3. Technology: Can high-frequency read/write data such as login state, progress, and favorites maintain low latency and eventual consistency under high concurrency?

With these goals in mind, this article follows the chain of “account authentication → playback progress sync → favorites and messaging → membership entitlements” and walks through the design considerations for each module.

2. Account System and Login Authentication

2.1 Registration and Login Methods

Common login methods include username/password, phone verification codes, email verification, and third-party account login based on standard industry open authorization protocols. Several design principles are recommended:

• Unified identity: Regardless of the registration method, everything maps to the same internal user ID (UID), decoupling “login credentials” from “user identity.”
• Separate credential and user tables: Phone numbers, emails, and third-party accounts are stored as individual “login credential” records attached to the user table, making it easy to bind and unbind them later.

An illustrative schema:

CREATE TABLE user_account (
  uid        BIGINT PRIMARY KEY,
  nickname   VARCHAR(64),
  status     TINYINT,        -- account status: active/banned/deactivating
  created_at DATETIME
);
CREATE TABLE user_credential (
  uid         BIGINT,
  cred_type   TINYINT,       -- 1 password, 2 phone, 3 email, 4 third-party
  cred_value  VARCHAR(128),  -- phone/email/third-party unique identifier
  secret_hash VARCHAR(256),  -- password hash, empty for non-password credentials
  UNIQUE KEY (cred_type, cred_value)
);

2.2 Session Management: Dual-Token Approach

How do you maintain login state after a successful login? The industry-standard approach is a “short-lived access token + long-lived refresh token” dual-token scheme:

• Access token: Short validity (e.g., 15 minutes to 2 hours), carried with every request. The server can verify the signature statelessly, making it naturally suited for horizontal scaling.
• Refresh token: Long validity (e.g., 7 to 30 days), used only to exchange for a new access token, with a rotation strategy—each refresh immediately invalidates the old refresh token. If the same refresh token is detected being used twice, it can be judged as leaked, and all sessions for that user are forcibly terminated.

This mechanism balances “staying logged in” with “account theft risk”: even if an access token leaks, the attacker’s window is extremely short.

2.3 Security Hardening

• Passwords must be stored using an adaptive slow hashing algorithm with a random salt, never plaintext or simple hashes.
• Login endpoints should be rate-limited separately by IP, device fingerprint, and account, with secondary verification triggered for anomalous behavior such as logins from unusual locations or high-frequency failures.
• The server should maintain a “device session list,” allowing users to view and forcibly log out unfamiliar devices from their profile—a highly visible security capability with low implementation cost.

3. Multi-Device Playback Progress Sync

“Cross-device playback progress sync” is a core experience requirement for video products and one of the trickiest parts of the user system: playback progress is inherently high-frequency-write data with concurrent updates from multiple devices.

3.1 Data Model

CREATE TABLE play_history (
  uid        BIGINT,
  content_id BIGINT,       -- content ID (episode/comic chapter/match replay)
  progress   INT,           -- playback position in seconds
  duration   INT,           -- total duration
  device_id  VARCHAR(64),   -- reporting device
  version    BIGINT,        -- monotonically increasing version number
  updated_at DATETIME,
  PRIMARY KEY (uid, content_id)
);

3.2 Sync Strategy

• Uplink: The client periodically reports during playback (e.g., every 30 seconds and on pause or exit), carrying the local version number.
• Downlink: After a user logs in on a new device, the most recent playback list is fetched in reverse updated_at order, enabling “continue watching on another device.”
• Conflict resolution: When multiple devices update progress for the same content simultaneously, “version number first, timestamp as fallback” is recommended—the higher version number overwrites the lower one; when version numbers match but content differs, the newer timestamp wins. For episodic content, semantic-level merging can also be applied: if device A has watched episode 5 while device B stopped at episode 3, take the later episode, matching the user expectation of “continuing the series.”

3.3 Performance and Storage

Playback history is a classic “write-heavy, read-heavy, recently-active-data-only” scenario:

• Write side: Avoid full persistence to the database every 30 seconds. A “memory cache aggregation + periodic batch flush” write-coalescing strategy can merge thousands of progress updates into a single batch write.
• Read side: Recent records stay resident in memory cache, returning directly on hit; historical cold data is sharded by user or archived to low-cost storage.
• Idempotency: The reporting endpoint must be idempotent—resubmitting the same version produces no side effects.

4. Favorites and Personal Content Library

Favorites differ from playback history in that they represent a content list actively built by the user, with higher reliability requirements—a complaint about a lost favorite is far more serious than a progress discrepancy. Key design points:

1. Model favorites as entities: Don’t just use a boolean “favorited” flag. Model it as a two-layer “folder + item” structure, supporting multiple folders, manual ordering, and public/private attributes.
2. Reliable write path: Favorite operations should be written directly to the database (or asynchronously via a message queue but guaranteed not to be lost). Cache is only for read acceleration, and the database is the source of truth for cache backfill on invalidation.
3. Count consistency: Statistics such as total favorites and content favorite counts should be generated through asynchronous accumulation or periodic reconciliation, avoiding hot-row contention in the database under high concurrency.

5. Messages, Activity Feeds, and High-Concurrency Interactions

5.1 Message Categories and Channels

Platform messages generally fall into three categories: system notifications (announcements, entitlement expiration reminders), interaction notifications (comment/bullet chat replies, being favorited, being followed), and business reminders (new episodes of followed content). A unified message center is recommended: a single message table tagged by type, with the client filtering and rendering by type; unread counts are stored separately in cache with atomic increment/decrement, and read operations never hit the database.

5.2 Peak Shaving for Interaction Traffic

Bullet chat and comments are typical burst-write traffic: when popular content updates or live matches occur, write peaks can reach dozens of times the daily average. Common practices include:

• The access layer performs rate limiting and automated content safety review first, intercepting violating content before it enters the write path.
• A message queue shaves peaks and fills valleys, with consumers batch-writing to the database or data warehouse for later retrieval and analysis.
• Separate display from storage: Online display only pulls recent hot data; historical interaction content is stored offline and retrieved on demand.

6. Membership Entitlement System

The essence of paid membership is an authorization model of “user × entitlement × time range”:

CREATE TABLE user_entitlement (
  uid          BIGINT,
  entitlement  VARCHAR(64),  -- entitlement code: HD, ad-free, exclusive content, etc.
  start_time   DATETIME,
  end_time     DATETIME,     -- expiration time
  source_order BIGINT        -- source order, for traceability and after-sales support
);

Authorization logic should be isolated into an independent entitlement service: content access control only checks “does this user currently hold this entitlement” rather than scattering membership checks across business code. This way, when implementing entitlement stacking (buy one year, get one month free) or cross-device sharing (subscribe on mobile, use on TV), only the entitlement service logic needs adjustment, keeping regression testing scope manageable.

7. Overall Architecture Recommendations

Connecting the modules above, a scalable content platform user system typically has the following shape:

1. Service-oriented decomposition: Accounts, sessions, progress, favorites, messages, and entitlements each become independent services, routed through a unified gateway after authentication, communicating internally via APIs or messages, with fault isolation so failures don’t cascade.
2. Differentiated read/write treatment: Progress data favors caching over storage, favorites data prioritizes storage, and interaction data emphasizes asynchronous peak shaving.
3. Unified idempotency and conflict strategy: All “multi-device writable” data must have conflict resolution rules involving version numbers or timestamps—this is the lifeline of multi-device experience.
4. Observability: Core metrics such as login success rate, sync latency, and queue backlog should feed into monitoring and alerting. Any degradation affecting the “post-login experience” should surface immediately.
5. Cloud deployment selection by general categories: Relational databases for accounts and favorites, in-memory cache for sessions and progress, message queues for interaction writes, object storage for static assets, plus the cloud platform’s general logging and monitoring services to complete the observability loop.

8. Conclusion

The user system has no flashy algorithms, yet it is the foundation for retention and paid conversion on content platforms. Doing two things well—“login means trust” and “switching devices means seamless”—retains users better than any marketing. Teams are advised to establish three conventions early in the project: unified UID, versioned sync, and idempotent reporting. Otherwise, they will easily fall into the rework trap of multi-device data overwriting each other and fragmented experiences later on.