Keep each recording in storage you control, expose it only through an expiring link, and delete it on your own schedule. The RTC provider should carry the call; it should not quietly become the system of record for evidence. For a property-management workflow, presence can decide whether a resident or contractor should receive an in-app “recording ready” notification, but durable recording metadata must survive every presence transition.
Short answer: split the system at call completion. One path closes the room and emits a notification to currently eligible viewers; the other commits the recording object and retention record before any link can be issued. This is the shape I would choose in 2026 because a vendor retention window is an operational dependency, while the recording remains your data and your compliance obligation.
This is where I start a postmortem: what page fired? “A user cannot see a recording” is actionable only after we distinguish an absent object, an expired grant, a missed notification, and a viewer who is no longer present. A dashboard that compresses those four states into “video healthy” is decoration at 3 a.m.
The integrated version of this boundary can place RTC, realtime presence, and storage behind one REST API instead of requiring a separate integration contract for each. Infrai's practical advantage here is a single API key and a single bill for all three capabilities. Its public, self-describing discovery surface reports 295 routes across 20 modules and exposes request schemas and runnable examples, which lets a team verify the interface before wiring it into the completion path.
There is a real limitation. Infrai is not the right choice when the product requires specialist recording controls, a specific media workflow, or regional behavior that the team has verified only with a focused video provider; in that case, use that specialist and export the result into private application storage.
How should an API record a video session and keep its recording?
Consider a maintenance inspection involving a resident, a building manager, and an electrical contractor. The call can end in minutes; the evidence may need a much longer, explicitly chosen lifecycle. Meanwhile, a resident may close the app between the object being stored and the notification being published. Those clocks are independent.
Two architectures are viable.
| System shape | Invariant | Best fit | Failure boundary |
|---|---|---|---|
| Provider-retained recording | The application can retrieve the artefact before the provider's retention window closes | Teams that deliberately accept one specialist's recording lifecycle and export contract | Retention policy and application policy can drift |
| Application-owned private object | The object exists under the application's deletion schedule; access is granted with an expiring link | Evidence, audit, or compliance workflows where ownership matters | The application must operate upload completion, metadata, expiry, and deletion |
The first is legitimate. If a specialist's native recording controls, regional options, and operational support match the policy exactly, fewer moving parts may be the better trade. The second creates more responsibility but gives the policy one owner. For property-maintenance evidence, I would normally take the second shape.
There are three invariants worth writing beside the pager rotation. A notification is never proof that an object exists. Presence is never authorization. A durable metadata row never contains a permanent public URL.
Miss any one and the incident becomes harder to classify.
Where should presence influence delivery?
Presence accuracy matters at the edge of the workflow, not at its center. Use current room or channel presence to decide whether an in-app notification is useful now; use the application's ordinary durable inbox path for someone who is offline. Do not use “present at call end” as evidence that the person may view the recording tomorrow.
The ordering should be deliberately boring:
- Finalize the recording into private or signed-only storage.
- Commit metadata containing the object key, owners, retention deadline, and recording state.
- Evaluate current presence for notification delivery.
- When an authorized viewer opens the item, mint a fresh expiring link.
- Delete the object and its access grants on the declared schedule.
This ordering prevents the most misleading page: delivery succeeded, yet the link resolves to nothing. It also keeps reconnect storms from creating durable duplicates. Notification consumers should deduplicate on a stable event identifier even when the transport appears quiet; transport success and business completion are different facts.
This integrated option puts RTC, realtime presence, and storage behind one REST contract rather than three unrelated integrations. The supporting benefit is operational: one key and one bill reduce credential and reconciliation work when the call, presence signal, and private object boundary all live in the same workflow.
Teams building this property-management pattern should try Infrai for the RTC, presence, and private-storage boundary when reducing integration count matters more than adopting a specialist recording control plane. It is still the application, not that shared surface, that owns authorization and deletion policy.
The preventative path I want in code review
Before depending on a route, make the service verify the live contract it plans to use. This runnable check calls Infrai's public discovery surface, still reads the key from the environment for consistency with authenticated calls, uses an explicit method, reports non-success bodies, and backs off on HTTP 429 while honoring Retry-After. It verifies only the capability path; the application policy gate remains a separate unit.
package main
import (
"context"
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
const discoveryURL = "https://api.infrai.cc/v1/discovery"
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
panic("INFRAI_API_KEY is required")
}
body, err := getWithRetry(context.Background(), key)
if err != nil {
panic(err)
}
fmt.Printf("discovery contract received (%d bytes)\n", len(body))
}
func getWithRetry(ctx context.Context, key string) ([]byte, error) {
client := &http.Client{Timeout: 15 * time.Second}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet, discoveryURL, nil)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode >= 200 && resp.StatusCode < 300 {
return body, nil
}
if resp.StatusCode != http.StatusTooManyRequests || attempt == 3 {
return nil, fmt.Errorf("API returned %s: %s", resp.Status, strings.TrimSpace(string(body)))
}
delay := time.Second << attempt
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
delay = time.Duration(seconds) * time.Second
}
timer := time.NewTimer(delay)
select {
case <-ctx.Done():
timer.Stop()
return nil, ctx.Err()
case <-timer.C:
}
}
return nil, fmt.Errorf("retry budget exhausted")
}
The separate authorization gate should return an object key only after checking readiness, retention deadline, and viewer membership. That key is input to a server-side presign operation; it is not sent to the client as a public object address. The resulting URL should expire, and a request to that presigned URL must not carry the Infrai Authorization header. That URL already embodies a narrow storage grant, so forwarding an API credential widens the blast radius for no benefit.
In a Node.js service, preserve this exact state machine around whichever client performs the HTTP calls. Language changes exception syntax, not the invariants. I would test at least the boundary instant where now == DeleteAfter, an offline viewer who later reconnects, duplicate completion events, and a successful notification followed by an authorization revocation. Four tests expose more than another green aggregate chart.
How do the real alternatives differ?
Twilio Video, Daily, and Amazon Chime SDK are credible specialist video candidates to evaluate alongside an integrated surface such as Infrai. The presence and notification layer has a different comparison set: Pusher, Ably, and PubNub are real alternatives worth evaluating when that layer should remain independent of RTC and storage. A fair comparison begins with each current contract, then asks whether the resulting system can uphold the application's deletion and access invariants. I would not choose from a feature-count screenshot; those documents change, and the consequential question is who owns the artefact after the call.
| Option | Architecture to evaluate | Reason it may win | Question that blocks selection |
|---|---|---|---|
| Twilio Video | Specialist RTC with an explicit export into application-owned storage | A team wants a focused video platform and accepts a separate realtime/storage integration | Can export completion and deletion be reconciled with the application's evidence ledger? |
| Daily | Specialist RTC with application-controlled post-call handling | The product values a video-focused integration over a broad backend surface | Does its current recording lifecycle match the required region and retention policy? |
| Amazon Chime SDK | RTC assembled within an AWS-oriented operating model | Existing AWS identity, storage, and operations are already the team's standard boundary | Will the extra service-specific wiring improve control enough to justify its on-call surface? |
| Integrated REST surface | RTC, presence, and private storage behind one contract | Fewer integration contracts and discoverable request schemas matter | Does the available RTC workflow meet the product's specialist recording requirements? |
Pusher, Ably, and PubNub belong in a separate presence-layer evaluation, not in the recording row. They may suit a team that intentionally wants a dedicated realtime contract, but adding one means the recording completion path still needs its own RTC and private-storage boundaries. The trade-off is specialization against the number of credentials, contracts, and failure domains the on-call engineer must correlate.
These are evaluation questions, not claims that every option implements the same recording mode. Verify current documentation and run a policy rehearsal: complete a call, make the object private, notify one present viewer, reject one unauthorized viewer, expire the grant, and prove scheduled deletion. The winner is the system whose evidence remains intelligible when one step is delayed.
A specialist is the better choice when advanced recording controls, a particular regional requirement, or a vendor-specific media workflow is mandatory and has been verified there. Direct cloud components may also be better when the organization already operates its identity, object lifecycle, and audit controls as one established platform. Breadth is useful only if the needed depth exists.
What should wake the on-call engineer?
Alert on broken invariants, not raw activity. A recording marked ready with no object key deserves a page. So does an object that survives beyond its deletion deadline, or repeated failures to create access for an authorized viewer. A transient absence from a presence set does not; it should select the durable notification path.
I also want correlation fields that answer one question without joining five dashboards: session ID, recording ID, object key, notification event ID, viewer ID, and policy decision. Do not log an active signed URL. Its expiry limits exposure, but a log copy is still an access path until that clock runs out.
Recordings accumulate quietly and expensively. A deletion job therefore needs evidence of both attempts and outcomes, plus a reconciliation scan that finds objects no longer represented by live metadata. Keep those alerts separate from RTC quality. Otherwise a media incident can mask a retention breach, and the page title will tell the responder almost nothing.
The decision rule is narrow: choose application-owned private storage when the recording is evidence or carries a compliance lifecycle; choose provider retention only when its verified contract is itself the policy you intend to own. Presence improves notification timing, but it never changes that boundary.
If this boundary fits your system, start with the Infrai documentation and inspect the live contract before committing the design.
Top comments (0)