| Web Services || Provide functionality required for the web client and developer APIs. These are stateless services that use the PostgreSQL database and shared storage to manage the application state. || Active/active stateless clustering that can have multiple active instances to scale out request demand and enable seamless failover using a NGINX load balancer. |
| Research Service Using Qlik || Optionally deployed in a multi-node architecture with shared access to a shared folder that contains application data. || Active/active. Failover should be configured based on Qlik's recommendations. A load balancer can be deployed to distributed load for seamless scale-out performance and high availability. |
| Processing Service || Also referred to as on-demand mode processing. This service is responsible for video decoding, rendering, object extraction, and classification that require one or more GPU cards. || Active/active. Multiple servers can be deployed at a single site to scale video processing requirements and provide high availability. All nodes in the solution are clustered. An application-level load balancing algorithm/policy determines the preferred node for a given session. |
| Alert Processing Service || Also referred to as real-time processing mode. This service supports the delivery of proactive responses to critical events for increased safety and security, with customizable alerts, alert reporting, and browser notifications. || Active/active. Multiple servers can be deployed at a single site to scale video processing requirements and provide high availability. All nodes in the solution are clustered. An application-level load balancing algorithm/policy determines the preferred node for a given session. |
| Fetching Service || The Fetching service is responsible for fetching the video footage from the VMS. || This service can be installed on multiple hosts to provide high availability. |
| Video Streaming Gateway Service (VS Server) || Used for camera management, VS service is responsible for starting, stopping, and managing additional BriefCam services || Active-Passive is the only deployment model for the VS Service. A second VS Service must be deployed on a different server and keep it on standby by making sure the service is stopped and not in use. The primary instance must be monitored to detect if it goes down. The standby instance must then be started either manually or automatically on the redundant server. Once the service starts, it connects to the database and continue where the failing service left off. |
| PostgreSQL Database Service || As BriefCam processes video, it detects and recognizes objects, along with information about their type and attributes. Objects are then classified according to different classes, attributes, color, dwell time, size, and speed. BriefCam processes the video stream once and then stores all metadata in the database. || |
PostgreSQL offers various ways to archive and replicate the primary database for backup, high availability, and load balancing scenarios.
BriefCam recommends implementing a trigger-based master-standby replication.