Ayonix Video Analytics

Deployment architecture

Multi-site management: consistent rules across the whole estate

In short

Multi-site management applies one rule template, threshold set and software version policy across many sites, and collects health and events centrally. Without it, each site drifts into its own configuration and cross-site comparison becomes meaningless — which is the commonest failure in large analytics estates.

Who this suits

  • Estates of comparable sites — retail chains, depot networks, branch estates
  • Organisations that need cross-site benchmarking to be defensible
  • Deployments rolling out in phases across many locations
  • Operations teams managing sites they rarely visit
  • Estates where configuration drift has already undermined an earlier deployment
Manager reviewing factory, retail, transit and parking sites in an operations centre
Conceptual illustration of multi-site operational oversight. AI-generated conceptual image, not a customer deployment.

Architecture

How it is put together

  • Each site processes locally, in an edge or on-premise configuration.
  • A central management layer holds rule templates, thresholds and version policy.
  • Templates are applied to site groups, with documented per-site overrides where geometry demands them.
  • Events, aggregate series and health are collected centrally for estate reporting.
  • Site groups allow different formats — large store, small store, depot — to carry different templates.
Multi-site video analytics architecture diagram

Characteristics

What this model means in operation

The properties below are what actually differentiate the deployment models from each other.

Bandwidth
Only configuration, events, metrics and health traverse the WAN. Bandwidth scales with site count and activity, not with camera count or resolution.
Latency
Local alerting is unaffected by the central layer. Configuration changes propagate on connection and apply at the next rule reload.
Privacy
Video remains at each site. The central layer holds configuration, events, aggregate metrics and health only.
Resilience
Sites run on their last known-good configuration during a disconnection. A central-layer outage prevents configuration changes and reporting, not detection or local alerting.
Central management
This is the whole purpose of the model: templates by site group, documented per-site overrides, version policy, and one place to see which sites have drifted from their template.
Software updates
Version policy per site group, with staged rollout and the ability to hold a version. Estates should pilot on a small group before estate-wide rollout — a bad version applied everywhere at once is the failure mode this design exists to prevent.
Health monitoring
Estate-wide view of site, node and camera health, with cameras below readiness threshold surfaced explicitly. In a large estate this is usually the first thing operations actually uses daily.
Logging
Central aggregation of operational events and configuration changes, with a full audit trail of who changed which template and when.
Backup
Central configuration and templates are backed up centrally, so any site can be rebuilt from the template plus its documented overrides.
High availability
Central-layer redundancy protects configuration and reporting. Site-level redundancy is decided per site based on its operational importance.
Scaling
Designed for estate growth. Adding a site means assigning it to a group and completing its readiness review, rather than designing a configuration from scratch.

Planning

Sizing inputs, cost and limitations

Hardware sizing inputs

  • Number of sites and their grouping by format
  • Camera count per site and per group
  • Event volume per site, which drives central-layer sizing
  • Aggregate series retention and reporting granularity
  • Number of distinct rule templates the estate genuinely needs
  • Rollout rate, which determines how much readiness-review capacity is required

Sizing is done against your actual stream profiles and rule set by Ayonix. No channel-count or throughput figure is published on this site, because none has been supplied.

Cost considerations

  • Central platform cost, amortised across the estate
  • Per-site hardware, which dominates the total in large estates
  • Readiness-review effort per site, frequently underestimated in rollout planning
  • Reduced per-site operations effort once templates are established
  • Cost of configuration drift if multi-site management is omitted — usually paid later as unusable data

Limitations

  • Templates transfer but tuning does not; every site still needs its own readiness review and threshold validation.
  • Cross-site comparison is only valid where camera geometry is genuinely comparable.
  • The central layer is a real dependency for configuration and reporting and must be designed accordingly.
  • Per-site overrides must be documented, or the estate drifts back into inconsistency.

Frequently asked questions

Can one rule template work across every site?

The template design usually transfers; the thresholds rarely do. Camera heights, entrance widths and lighting differ, so each site needs its own readiness review and validation. Templates make configuration consistent, not automatic.

How do we keep cross-site comparison honest?

By documenting camera geometry comparability and coverage completeness per site, and by reporting availability alongside every metric. A site with a lower figure because its camera was down for two days is a data-quality issue, not a performance one.

What breaks without multi-site management?

Configuration drift. Each site ends up with its own thresholds, nobody knows which sites are comparable, and estate-level reporting stops being defensible. It is the commonest reason a large analytics rollout fails to deliver the reporting it was bought for.

Compare with other models

Author
Gabriel Bamola, Chief Marketing Officer, Ayonix
Technical review
Dr Sadi Vural, Founder and Chief Executive Officer, Ayonix
Published
Last reviewed

Get an architecture review for your estate

Site count, connectivity, data-residency constraints and whether alerting must survive an outage decide the model. An architecture review works through those with you and produces the sizing inputs Ayonix needs.

Request an architecture review Compare all deployment models