Solution ArchitectureAttendance Platform Proposal
Download PDF

Solution Architecture Proposal

Multi-Site Facial Recognition Attendance System

Edge-first attendance, presence and movement tracking across 15+ office locations.

Raw video never leaves the building. Attendance never stops. Recognition never depends on a third party.

Read the architecture Download PDF

Scenario by: Fahd Khan, Head of ITCymax Technologies

Muhammad Bilal

Senior Full-Stack Engineer / Solution Architect

Key numbers

100,000x

Bandwidth reduction at the edge

0

Inbound ports open at any office

Week 8

Pilot office live

Week 16

All 15+ sites live

01

The core decision

One choice determines the bandwidth profile, the privacy posture and the availability story of this entire platform.

Recognition happens inside each office, not in the cloud.

Each site runs a small on-premise AI server that recognises faces locally and sends only lightweight encrypted events to the cloud. Nothing else crosses the boundary.

Three consequences follow directly from that single decision.

  1. Biometric data never leaves company premises. Faces become mathematical embeddings on site and the images are discarded.
  2. Offices keep recording attendance through internet outages. The link to the cloud carries reporting, not recognition.
  3. Recognition never depends on a third party. Inference runs on hardware the company already owns, so no per-image external dependency is introduced.

02

High-level architecture

Three tiers. Recognition completes in tier one, so tiers two and three never see an image.

Three tier system architecture Tier one, office site, replicated at 15 or more locations: IP cameras using RTSP on an isolated VLAN with PoE, feeding an edge AI server that detects, matches and checks liveness, feeding a local buffer holding an offline event queue. Attendance events travel over a WireGuard VPN using MQTT TLS at QoS 1 to tier two, the central cloud in an AWS VPC: an EMQX broker feeds an attendance engine built on NestJS and BullMQ, which feeds PostgreSQL on RDS with pgvector, supported by Redis for cache and queues and S3 for flagged crops on a 60 day lifecycle. REST and WebSocket carry live updates to tier three, applications: an admin dashboard on Next.js with live view, reports and dwell time, and HR enrollment covering registration, consent and RBAC. TIER 1 · OFFICE SITE Replicated at 15+ locations IP cameras RTSP · isolated VLAN · PoE Edge AI server detect · match · liveness Local buffer offline event queue attendance events · WireGuard VPN · MQTT TLS QoS 1 TIER 2 · CENTRAL CLOUD AWS VPC EMQX broker MQTT ingress Attendance engine NestJS · BullMQ PostgreSQL RDS + pgvector SUPPORTING SERVICES Redis cache · queues S3 flagged crops · 60 day lifecycle REST + WebSocket · live updates TIER 3 · APPLICATIONS Operated by HR, security and site management Admin dashboard Next.js · live view · reports · dwell time HR enrollment registration · consent · RBAC TIER 1 · OFFICE SITE Replicated at 15+ locations IP cameras RTSP · isolated VLAN · PoE Edge AI server detect · match · liveness Local buffer offline event queue attendance events · WireGuard VPN MQTT TLS QoS 1 TIER 2 · CENTRAL CLOUD AWS VPC EMQX broker MQTT ingress Attendance engine NestJS · BullMQ PostgreSQL RDS + pgvector SUPPORTING SERVICES Redis cache · queues S3 flagged crops · 60 day lifecycle REST + WebSocket · live updates TIER 3 · APPLICATIONS HR, security and site management Admin dashboard Next.js · live view · reports · dwell HR enrollment registration · consent · RBAC
Office site, replicated 15+ times Central cloud, AWS VPC Applications

03

Capacity estimation

Assumptions: roughly 3,000 employees and 150 cameras. Sizing came first. The decisions in the next section are consequences of these four numbers.

Capacity estimates and what each one implies
DimensionEstimateWhat it means
Event volume 50,000 events per day, peak 20 per second One NestJS consumer with 100x headroom.
Data growth 3.6 GB per year, ~200 bytes per event One PostgreSQL holds a decade.
Embeddings ~10 MB 5,000 x 512 floats Fits in memory on every edge box.
Video, if streamed 600 Mbps continuous, 150 cameras The number that rules out cloud processing.

04

Architecture Decision Records

Seven decisions, each with the options that lost and the trade-off accepted. One record opens at a time.

Options considered

  1. A

    Stream all video to the cloud

    600 Mbps of continuous upload, an outage kills attendance outright, and raw video leaves every office.

  2. B

    Hybrid: detect at the edge, recognise in the cloud

    The cloud stays on the hot path, so an outage still stops recognition.

  3. C

    Full edge processing, events only

    Recognition completes on site. Only structured events travel.

Decision

Option C. Bandwidth drops roughly 100,000x, availability decouples from the internet, and privacy exposure collapses to a mathematical vector.

Trade-off accepted We operate 15 edge devices. Mitigated by identical container images, signed updates and cold spares.

The reasoning

Managed APIs bill per image. Across 150 cameras running continuously, that is a fee that recurs forever and grows with every camera added, while edge hardware is a one-time acquisition. It also sends every employee's face to a third party and makes recognition depend on the internet connection.

Relative cumulative cost over time

deployment time relative cumulative cost crossover, early managed API, per-image fees edge, one-time hardware

Shape only, no units. The managed line has no ceiling because it is charged per image; the edge line flattens once the hardware is acquired.

InsightFace (RetinaFace for detection, ArcFace for embeddings) leads public accuracy benchmarks and runs entirely on the edge device.

Decision

Build on InsightFace at the edge. No training is needed, only enrollment using pretrained models. Managed APIs suit low-volume bursty work; continuous video is the workload where per-image billing never stops.

Trade-off accepted We own accuracy tuning. Mitigated by a dedicated pilot tuning window in weeks 9 to 11.

Options considered

  1. A

    Raspberry Pi plus accelerator

    Caps out at 2 to 3 streams, so an office would need 4 or more units, multiplying the failure surface it was meant to reduce.

  2. B

    x86 with an RTX GPU

    Easiest to source in Pakistan and the UAE, but higher power draw and a larger physical footprint.

  3. C

    NVIDIA Jetson Orin NX

    Purpose-built for this workload, 10 to 25 W, DeepStream native, comfortably 8 to 16 streams.

Decision

Jetson Orin NX as primary, x86 as an approved alternative, so the supply chain can never block rollout. One device per office, identical containerised stack on both.

Trade-off accepted Two validated hardware paths instead of one. The container image is the constant, so the operational model does not fork.

Options considered

  1. A

    HTTPS polling

    No delivery guarantees without hand-building retry, backoff and deduplication. That is a queue, written badly.

  2. B

    Kafka at the edge

    A datacenter tool for a few hundred messages per minute. A freight train delivering envelopes.

  3. C

    MQTT over TLS with EMQX

    QoS 1 at-least-once delivery, persistent sessions that resume after an outage, featherweight client.

Decision

MQTT for the last mile. Kafka can slot in cloud-side later if volume ever justifies it, without touching a single office.

Trade-off accepted One more component to run. EMQX is a single small, well-understood container.

5,000 employees at 512 floats each is about 10 MB of vectors in total.

Options considered

  1. A

    A dedicated vector database

    Milvus, Pinecone and Weaviate are built for billions of vectors. Deploying one here adds a distributed system to operate for a scale problem that does not exist.

  2. B

    pgvector inside the PostgreSQL we already run

    Answers exact nearest-neighbour search in under 1 ms, with no new operational surface.

Decision

PostgreSQL with pgvector. Hot-path matching happens in memory on each edge box, and PostgreSQL is the source of truth syncing enrollments down. Matching at the edge, truth in the cloud.

Trade-off accepted If the identity set ever grows by orders of magnitude, a dedicated vector store can be introduced behind the same interface.

Options considered

  1. A

    Self-managed VPS

    Maximum control, but backups, patching, failover and the biometric compliance story all become in-house responsibilities.

  2. B

    AWS managed services

    RDS point-in-time recovery, S3 lifecycle rules, IAM audit trails, and ISO 27001 and SOC 2 behind the platform.

Decision

AWS, for a biometric system of record. Managed durability and an inherited compliance posture are worth more here than the operational control a self-managed host would give back.

Trade-off accepted Less low-level control and a dependency on one provider. The VPS route stays documented as an alternative, with the transfer of responsibility stated openly rather than buried.

Options considered

  1. A

    Public MQTTS endpoint

    Creates a public attack surface plus a certificate lifecycle to manage across 15 sites.

  2. B

    IPsec

    Mature but heavy to configure and brittle on the dynamic IPs most branch offices actually have.

  3. C

    WireGuard

    Roughly 4,000 lines of auditable code, fast, and it survives dynamic IPs gracefully.

Decision

WireGuard. Zero inbound ports at any office, and no camera is ever visible from the internet.

Trade-off accepted Key distribution across sites must be managed. Handled by the same signed provisioning process that images each device.

05

System design

How each tier behaves, from camera to report.

Edge

Recognition at the point of capture

  • Capture. PoE cameras stream RTSP over an isolated VLAN. No camera has a route to the internet.
  • Decode. DeepStream decodes every stream on the GPU, keeping the CPU free for orchestration.
  • Detect. RetinaFace locates faces in each sampled frame.
  • Liveness. A liveness check rejects printed photos and phone screens before any match is attempted.
  • Embed. ArcFace produces a 512-d embedding. The source image is discarded unless flagged.
  • Match. An in-memory index matches against the site roster: accept above 0.6, review 0.4 to 0.6, otherwise unknown.
  • Publish. Events go out over MQTT at QoS 1 through the WireGuard tunnel.
  • Survive. A SQLite queue buffers through outages and resyncs with original timestamps.
  • Report health. The box self-reports continuously. A degraded site shows in Grafana within one minute.

Cloud

The system of record

  • Ingest. EMQX receives events from every site through WireGuard tunnels, inside the VPC.
  • Consume idempotently. The NestJS engine keys on globally unique event IDs, so at-least-once delivery never double counts a person.
  • Build the day. First detection at an entry camera opens the working day, the last closes it. Zone-to-zone events build movement paths and dwell time.
  • Persist. PostgreSQL on RDS is the single system of record, including enrollment embeddings via pgvector.
  • Serve and queue. Redis backs the live cache and BullMQ queues for reports, exports and roster distribution.
  • Store selectively. S3 keeps only flagged crops, encrypted and auto-deleted after 60 days.

Applications

What people actually use

  • Dashboard. A Next.js app with live occupancy, per-employee timelines, dwell analytics, exception queues and exportable reports over WebSockets.
  • Enrollment. HR registers an employee from 5 to 10 reference images, captures consent and generates the embedding.
  • Lifecycle. Deletion on exit removes the biometric record and propagates to every edge device within minutes.
  • Access control. RBAC across four roles: HR admin, site manager, security and auditor.
  • Accountability. An immutable audit log records every human access to biometric data.

Data model

employees identity records sites one per location embeddings versioned by model cameras role: entry | area raw_events append-only · uuid · immutable truth attendance_days derived, rebuildable review_queue low confidence + unknown audit_log immutable · every human access recorded

raw_events is immutable truth; attendance_days is a derived view, rebuildable by replaying events.

Offline resilience

normal outage recovery Internet link UP DOWN UP Edge server recognise + publish recognise + buffer locally drain buffer + live Cloud real-time events site degraded + alert backfill with original timestamps time

Attendance recorded during an outage is never lost.

Recognition pipeline

Camera frame RTSP, sampled GPU decode DeepStream Face detect RetinaFace Liveness gate rejects photos and screens Embed 512-d ArcFace In-memory match against the site roster > 0.60 attendance event 0.40 to 0.60 human review queue < 0.40 unknown-person alert

The source image is discarded at the embed step unless the score falls into the review or unknown band.

Enrollment flow

1 HR captures 5 to 10 images varied pose and lighting 2 Quality check sharpness, pose, occlusion, exposure 3 Consent recorded stored as part of the employee record 4 Embeddings built ArcFace, 512-d, images then discarded 5 Stored in PostgreSQL pgvector, the single source of truth 6 Synced to all edges active in minutes Exit deletion mirrors this flow in reverse. Removed centrally, then from every edge within minutes.

Consent is captured before any embedding exists, so no biometric record is ever created without it.

06

Security and privacy

Biometric data raises the bar. Five layers, each with a stated control.

Network

  • Cameras on an isolated VLAN with no internet route
  • All site-to-cloud traffic inside WireGuard tunnels
  • Zero inbound ports open at any office

Data

  • TLS 1.3 in transit, AES-256 at rest
  • Embeddings stored in place of images. An embedding cannot be reversed into a face
  • Flagged crops deleted automatically after 60 days

Application

  • Short-lived JWTs with refresh token rotation
  • Role-based access control and rate limiting
  • OWASP review and an immutable audit log

Compliance

  • Written biometric policy, consent captured at enrollment
  • Aligned to UAE PDPL and GDPR principles
  • Documented retention and deletion procedures

Operations

  • Credentials in AWS Secrets Manager
  • Signed over-the-air updates to every edge device
  • Prometheus and Grafana alerting, plus tested encrypted backups

Network topology

OFFICE NETWORK Camera VLAN no internet route, no inbound path PoE switch powers and isolates every camera Edge server dual-homed: camera VLAN and office LAN Router outbound connections only WireGuard tunnel outbound only · zero inbound ports AWS VPC VPN gateway terminates every site tunnel EMQX broker MQTT over TLS, per-site credentials App services attendance engine, API, dashboard RDS PostgreSQL Redis cache, queues S3 flagged crops Monitoring · Prometheus and Grafana across the VPC

No camera, switch or edge device is reachable from the public internet. Every connection is opened from inside the office outwards.

07

AI-accelerated delivery

Where the schedule compression comes from, and where it does not.

Workstreams accelerated by AI-assisted development
WorkstreamWhat AI acceleratesTime saved
ScaffoldingNestJS modules, DTOs, MQTT consumers, dashboard components40 to 60% of boilerplate
Test suitesGenerated edge-case coverage for offline resync and idempotency50%+
Infrastructure as codeTerraform, Docker Compose, edge update tooling30 to 50%
DocumentationRunbooks, incident playbooks, operator guides60%+

What AI does not compress

  • Camera procurement and lead times
  • Physical installation and cabling
  • Compliance and legal review
  • Pilot accuracy tuning against real lighting
  • Stakeholder decisions

Governance

  • Every AI-generated line passes senior review before merge
  • Security-critical paths are double-reviewed
  • CI gates every change

AI raises throughput; accountability stays human.

Conventional

~24 weeks

~30 person-months

This proposal

16 weeks

~20 person-months

08

Team and resources

A small senior team, sized to the work rather than to the calendar. Field installation is contracted per city so rollout is not bottlenecked on a single crew.

Roles, headcount and responsibilities
RoleResponsibility
Solution architect / tech leadx1 Architecture ownership, AI-workflow direction and review, delivery leadership.
ML / computer-vision engineerx1 Model tuning, DeepStream pipeline, liveness, FAR and FRR targets.
Backend engineerx1 to 2 NestJS services, MQTT bridge, attendance engine, APIs.
Frontend engineerx1 Dashboard, enrollment module, live views.
DevOps engineerx1 VPN mesh, CI/CD, monitoring. Part-time after the initial setup.
QA engineerx0.5 Test strategy and pilot acceptance measurement.
Field techniciansper city Contracted camera mounting, cabling and rack installation.

Per-site equipment

Around 10 PoE cameras with IR-capable units at the entrances, one PoE switch, one edge AI device (Jetson Orin NX, or the x86 plus RTX alternative), and cabling and mounting. One cold-spare edge device is held per region.

Total engineering effort approximately 20 person-months with the AI-accelerated workflow, against roughly 30 conventionally.

09

Delivery timeline

Sixteen weeks from kickoff to all sites live, with a working pilot office at week 8.

  1. Phase 0

    Weeks 1 to 2

    Survey and sign-off

    Parallelised site surveys, camera placement plans, biometric policy drafting and architecture sign-off. Hardware is ordered on day one, so procurement runs behind the build rather than in front of it.

  2. Phase 1

    Weeks 3 to 8

    Build and pilot

    Edge pipeline, cloud services, dashboard MVP and enrollment built in parallel. The full pilot office goes live in week 8.

    Milestone: pilot office live

  3. Phase 2

    Weeks 9 to 11

    Harden

    Accuracy tuning against measured FAR and FRR targets, lighting edge cases, deliberate offline drills and an independent security review.

  4. Phase 3

    Weeks 12 to 16

    Roll out

    The remaining 14 sites in four overlapping batches. The rollout playbook is finalised by batch two, after which each site is a repeat rather than a project.

    Milestone: all 15+ sites live

Reference: the same scope conventionally estimates at 24 weeks.

10

Risks and mitigations

The six failure modes worth planning for, each with a concrete control.

Risk register
RiskMitigation
Poor lightingCamera placement standards, IR-capable entrance cameras, and pilot threshold tuning against measured FAR and FRR targets.
Spoofing attemptsLiveness detection at the edge, backed by an HR review queue for anything that scores low.
Connectivity lossLocal buffering with original timestamps, automatic resync, and alerting on a degraded site within one minute.
Regulatory changeEmbeddings-first storage, 60-day retention on flagged imagery, and a tested deletion path.
Hardware failureA cold spare held per region, with restore from cloud configuration in under an hour.
AI-assisted code qualityMandatory senior review, generated test suites, double review on security paths, and CI gates on every change.

11

Why this proposal

01

It shows its reasoning

Seven decision records, each carrying the alternatives that lost and why.

02

It is sized against reality

Capacity first, technology second. Every component is justified by a number.

03

It is delivered at modern speed

An AI-accelerated workflow under senior review, with a working pilot in week 8.

Happy to walk through any decision in detail.

Discuss this architecture Download PDF