Planning a mixed fleet above 10 million cameras

The deployment requirement is a mixture of continuous video and event uploads from a fleet exceeding ten million registered cameras. Registered sources, simultaneous streams, recognition samples, live viewers and retained footage are different workloads. This guide describes the implemented distribution controls and the engineering work required for that deployment; it is not a ten-million-camera performance benchmark.

Separate the traffic lanes

Lane	Path	Main sizing concern
Event snapshots and clips	Dedicated camera keys and the HTTP image/clip API behind regional application/ingestion nodes	Burst requests, average payload, processing queue and retained images
Continuous RTMP/SRT video	Camera-assigned receiving nodes	Aggregate bitrate, active connections, decoding CPU and sampled recognition
Pulled sources	Node-assigned, leased capture workers	Due-capture rate, source response times, bounded concurrency and backlog
Authorised live viewing	Shared source decoder on the serving/viewing node	Active source views, viewer traffic and viewing-node capacity
Full video retention	Explicitly provisioned recording/evidence workflow and regional storage	Video bitrate, retention, replicas, recovery and bandwidth

The receiver samples video for recognition. It does not automatically archive every original stream. If every camera's full video must be retained, provision and test the recording/storage system separately. Where operationally appropriate, keep original video regionally and send central events, approved crops and references.

Assign publishers to receiving nodes

Configure a stable node list on the API and receiving nodes. Example environment value, on one line:

CAMERA_RELAY_PUBLIC_NODES=[{"id":"ingest-1","host":"cams-1.example.com","rtmpPort":1935,"srtPort":8890},{"id":"ingest-2","host":"cams-2.example.com","rtmpPort":1935,"srtPort":8890}]

On the first receiver set CAMERA_RELAY_NODE_ID=ingest-1; on the second set CAMERA_RELAY_NODE_ID=ingest-2. Set each node's actual bind ports and application-ingestion origin. The names above are examples, not provisioned hosts.

The API uses stable rendezvous hashing of the camera record ID and node IDs to choose one receiver. Reordering the list does not move assignments. Adding a node moves only the cameras newly assigned to that node. Node removal or expansion still requires an orchestrated camera/encoder reconfiguration; this is not an automatic failover controller.

GET /api/v1/cameras/CAMERA_ID/connections returns the assigned publishing hostname and ports to a user with cameras:read and visibility of that camera. It returns one assignment, not the entire camera register or node list. The admin Connect panel and key-creation/rotation screens use that assignment. A receiving node refuses publishers assigned to another node.

Use DNS and regional network routing suitable for the deployment. A generic round-robin destination is not enough when an encoder must reach its assigned receiver. Receiver failure handling, spare capacity, DNS/network changes and encoder reconnection must be exercised in the acceptance plan.

Bound work per node

Control	Purpose
CAMERA_RELAY_MAX_STREAMS	Limits simultaneous authorised publishers on one receiving node; default 24. This is not the fleet-registration limit.
Camera intervalSec	Controls how frequently a published stream is sampled for recognition. It does not reduce the incoming stream's own bitrate.
CAMERA_PULL_WORKERS	Concurrent due-source capture jobs on a jobs node; default 8.
CAMERA_PULL_NODES	Stable comma-separated capture-node IDs, identical across API/jobs nodes.
CAMERA_PULL_NODE_ID	Identity of this capture worker node; defaults to jobs-JOBS_ID.
CAMERA_PULL_LEASE_MS	Claim lease with renewal while a capture runs; default 120000 ms.
CAMERA_PULL_BACKFILL_BATCH	Maximum legacy unassigned source records assigned in each background batch; default 100, or 0 to disable.
CAMERA_LIVE_MAX_SOURCES	Maximum distinct active live-view sources on a node; default 32. Additional sources receive HTTP 429.

Pull cameras are assigned a capture node when saved. Indexed due-time queries claim the next available record; lease tokens and renewal coordinate claims. The worker pool does not load all camera records or create a timer for every registered camera. When more sources are due than the workers can process, captures queue fairly by due time rather than creating unlimited decoders. Provision enough worker throughput to meet the capture-delay target.

Receiver revalidation batches active camera and key lookups rather than issuing a separate lookup pair for every stream. In-memory receiver state is bounded by that node's active-stream limit. Existing camera lists/selectors remain backend-paged and search-limited. Keep application, recognition, database, storage and regional ingestion resources sized independently.

Size the actual mixture

Record at least the continuous-video share, bitrate distribution, upload event rate, payload size, recognition sample interval, peak multiplier, retention, replication and live-view concurrency.

Continuous ingest bits/s = active continuous cameras × average bitrate
Recognition frames/s = active sampled streams ÷ sampling interval
Event requests/s = event cameras × events per day ÷ 86400
Daily event bytes = event cameras × events per day × average payload bytes

Example assumptions for ten million cameras: one million continuous sources at 1 Mbit/s and nine million event sources at 100 uploads per day, averaging 200 kB per event. This produces:

Example workload	Arithmetic result
Continuous incoming video	1 Tbit/s aggregate
Raw continuous video per day	10.8 PB, using decimal units
Continuous recognition at one frame per five seconds	200,000 sampled frames/s
Event requests per day	900 million
Average event request rate	About 10,417 requests/s, before bursts
Event payload per day	180 TB, before indexes, metadata, replicas or backups

These are workload calculations, not measured software capacity or a hardware quotation. Full video retention, recognition processing and image retention can dominate different parts of the deployment. Add regional bursts, outages and catch-up traffic; averages alone are insufficient.

Node count must come from a measured sustainable workload per node, with the agreed spare/failover margin. Do not derive fleet capacity by multiplying a small single-stream test or a configured connection cap by an arbitrary server count.

Migration and commissioning

1. Agree the traffic mixture, regional topology, processing and retention targets.
2. Provision receiver/capture node identities and compatible application/database/storage routing.
3. Build the camera assignment and due-capture indexes using the database's approved large-collection change process. Do not assume index creation is free on an existing ten-million-record register.
4. Assign existing source records in bounded batches and check node distribution. Existing captureNode assignments remain in place when the list changes; plan rebalancing explicitly.
5. Benchmark realistic encoders, difficult images, simultaneous streams and event bursts, with recognition enabled.
6. Test receiver loss, key revocation, disabled cameras, lease expiry, reconnection, ingestion failures and backlog recovery.
7. Measure percentile alert latency, recognition quality, source freshness, queue depth, sustained throughput and storage/restore behaviour before expanding.

The local test computer demonstrates functionality. It is not the infrastructure for ten million active cameras. See RTMP/SRT setup, camera APIs and capacity planning.