Events with Live Video and Replay

An attendee signs into a product launch, finds the right session, and starts watching. Later, they return to the recording and pick up where they left off. For the event platform, those moments connect registration, access rules, session descriptions, supporting materials, live video, and viewing progress. Building them as one experience helps customers move from discovering an event to participating in it, then returning to the content long after the broadcast ends.

How Harper connects the event experience and its video

Harper can host the event application and its media foundation on the same platform. The application serves session pages, checks attendee access, and stores event descriptions, registrations, supporting content, and viewing progress. Sign-in and session handling run inside the application cluster through Harper's OAuth plugin. It connects to a configured OAuth/OIDC provider, validates tokens, and integrates with Harper sessions. User-provisioning hooks can connect the signed-in person to local attendee records. Application logic then applies event access rules and issues time-limited playback authorization.

The media services receive encoded audio and video, retain segments and playlists, and serve live playback and recordings. The architecture below places the event application and media delivery in separate Harper clusters inside Fabric. Each stack combines application logic with local storage and represents nodes that can expand across regions. This lets teams size application requests and video delivery independently while using a common platform for both.

Fabric manages regional deployment and routing, with replication configured within each cluster. Media copies stay with the serving nodes, while event and attendee records stay with the application. Selected event-status updates connect the two through application integration. The access-setup connection represents the trust configuration used to validate playback authorization locally, rather than an application call for every video segment.

An external encoder packages camera and microphone input as HTTP Live Streaming (HLS) segments. Ingest stores them and publishes playlists when the referenced media is available. Replication distributes retained media to the configured delivery peers. The live playlist advances as the broadcast continues, and the recording playlist preserves the sequence for replay. A CDN can also front Harper delivery when audience size or delivery economics make it useful.

One attendee journey, two kinds of traffic

The attendee opens an event page, receives session details and playback authorization, then requests playlists and video segments directly from media delivery. Responses return over those HTTP connections. The player periodically sends viewing progress to the event application, which can offer “continue watching” on a later visit. Login, an open player, and active viewing are different signals, so the application defines what qualifies as attendance.

Alternatively, connect an event backend to a media delivery stack

A conventional platform uses an event application and database for pages, registrations, access rules, and progress. The backend integrates with the same upstream OAuth/OIDC provider and implements its session and attendee-mapping flow. A publishing application receives encoded segments, stores media and playlists in object storage, and updates event status. A CDN delivers authorized playback from edge caches, fetching missing or expired content from the storage origin. These are established building blocks, with application integration connecting the attendee experience to the broadcast.

Ingest and playlist logic can share one publishing application. The CDN validates the configured playback authorization and returns cached segments near viewers. Completed segments with unique URLs can have long cache lifetimes, while changing live playlists need short caching or revalidation. Event-status arrows show logical updates to event records through the application's integration path. Both designs keep video requests out of the event application's normal request path.

Where the experience needs coordination

A session becoming live, an attendee gaining access, and a recording becoming available must agree across the application and delivery systems. Teams coordinate event identifiers, authorization, publication order, cache rules, and recovery so a working video does not lead to a broken event page or an inaccessible replay. Harper retains those product responsibilities while bringing application logic, records, and media serving onto one platform, reducing the distinct backend systems to operate.

Scale the application and media according to their needs

Smaller workloads can colocate the event application and media services in one Harper cluster. That is a useful starting point when measured traffic leaves enough headroom. They share CPU, memory, disk, and network capacity, so separate services on the same node do not provide independent capacity or failure isolation.

The two-cluster design provides a stronger boundary as audiences grow. Scale media delivery for bitrate and concurrent viewers, and scale the application for page requests, access decisions, and progress updates. Keep large media blobs out of the application cluster and avoid a synchronous application lookup for every segment. Playback authorization needs defined expiry and renewal behavior, including how quickly access changes must take effect. Separate clusters reduce resource contention, while shared regional or platform dependencies still need recovery planning.

Validate the experience your audience will use

Mixed traffic and capacity. Run video delivery alongside event-page requests, sign-in callbacks, access checks, and progress updates. Measure application latency, playback buffering, bandwidth, replication lag, and resource use. Include peak arrivals and long sessions when deciding whether to share or separate clusters.

• Adaptive quality. Build an adaptive-quality workflow in Harper that coordinates aligned video renditions, with transcoding tooling and compute sized for the workload. Validate player switching on target devices and slower networks.

• Access and recovery. Test authorization on playlists and segments, token expiry, access changes, reconnects, and node or region failures. Confirm that a new serving destination has the media a playlist references.

• Event requirements. Define attendance signals, progress-update frequency, privacy and retention rules, captions, content protection, and latency targets. Keep high-volume viewing telemetry from overwhelming ordinary application requests.

‍

Related resources

See the Harper OAuth plugin for sign-in, session integration, and user-provisioning hooks. Its documented browser flow federates to an upstream provider, while authentication handling and attendee records live in Harper. See Harper’s guidance on colocating applications and choosing separate clusters, and the HTTP Live Streaming documentation for packaging and playback.

For media storage, start with Harper’s Blob field documentation. Blobs store large audio and video content separately from the record and support streaming without loading the entire file into memory. The streaming API example shows how to receive an incoming stream, store its blob reference, and begin reading the content while it is still arriving.

To build the delivery endpoint, see serving binary from a resource, which demonstrates returning a blob as an HTTP response with its content type. Review the accompanying error-handling guidance for interrupted streams. Where publication should wait for a complete media object, saveBeforeCommit: true waits for the blob to finish writing before committing its record.

For production deployments, review blob storage paths and retention settings. These cover where media is stored and how long superseded blobs remain available to support in-flight reads and replication.

‍

Start with the event experience you want to build

Bring your attendee journey, access rules, audience size, and recording requirements to a Harper architecture discussion. Map the application and media flows, choose the deployment boundaries, and validate them together. Build the live moment and the experience customers return to on the same platform, with capacity shaped around each workload.

‍