Skip to content

Runtime Boundaries

SyncTV is an application service. It is not a database, object store, media library, CDN, or public management platform. Confirm these boundaries before production deployment.

ComponentRoleProduction requirement
PostgreSQLSource of recordDurable storage, backups, and migration checks before upgrades
RedisShort-lived shared state and coordinationRecommended for production, required for multi-replica
SecretsTokens, credential encryption, OPAQUE, management authStable and protected from logs and repositories
TLSProtects login, tokens, cookies, MFA, and management trafficRequired for public entry points

PostgreSQL stores users, rooms, permissions, Provider instances, preferences, notifications, reviews, and audit data. Redis stores OAuth2 state, WebAuthn challenges, email codes, rate limits, token blacklists, cluster coordination, and cache invalidation state.

management gRPC, metrics, and internal debugging endpoints are for administrators and operators, not normal users or third-party clients. Use Unix sockets, private networks, VPNs, bastions, Kubernetes exec, or controlled scraping paths. If TCP management is enabled, set management.auth_token.

HTTP and gRPC are two transport entry points for the same business capabilities. Transport code owns path, query, JSON/protobuf, headers, stream body, and status conversion. Business implementation belongs in synctv-api/src/impls and synctv-core services, repositories, and providers.

When adding a capability, protobuf definitions describe the shared parameters, and HTTP/gRPC handlers translate into the same impl parameters. Keep Provider, playback, chat, file, and livestream logic in impls/core so transports expose consistent behavior.

Non-goalMeaning
Media storageSyncTV aggregates, resolves, and proxies external media; it does not replace object storage, cloud drives, media libraries, or CDNs
General transcoding platformTranscoding depends on Providers or upstream media systems
Public management planeManagement endpoints must not be exposed to the public internet
CDNProxy and slice cache do not replace bandwidth planning and edge distribution
Strongly consistent collaboration databaseRealtime is for room events and resource observation, not a database transaction boundary

Playback background workers use the current process’s active room set as their scheduling boundary. An active room here means a room with at least one realtime connection in the local ConnectionRuntime.

This boundary applies to duration probing, playback auto-advance, and playback resource lifecycle work. These workers run on every node because a follower can be the only process with connections for a room. Multiple nodes can host connections for the same room; duplicate attempts are handled by the database layer. Duration probing claims rows with locks and SKIP LOCKED, while auto-advance uses playback state transactions and optimistic versions.

Global hot-room statistics are presence and analytics data for room lists, admin views, and metrics. Playback background workers should read ConnectionRuntime::active_room_ids() so each node handles the rooms it is actively serving.

Leader election fits partition maintenance, cleanup, and other global singleton tasks. Playback lifecycle worker ownership comes from the node-local realtime connection set.