Designing an RFID + Face Verification Attendance System

The underlying problem: a scan is not an attendance record

Reading an RFID card is only the beginning of an attendance attempt. The card resolves an expected identity, but it does not prove that the student assigned to that card is physically present. The system also needs to decide which attendance session is active, whether the student is eligible for that session, and whether an earlier attempt was already accepted.

Treating every scan as a completed database write would blur identity, scheduling, and persistence into one fragile action. The architecture instead places an authoritative attendance engine between the device input and the stored result. A web simulator and a hardware-facing Device API must both pass through the same business rules.

Why 1:1 face verification follows RFID

A broad face search across every student is not necessary after RFID has supplied a candidate identity. The verification flow uses the card to resolve the expected student, then checks that particular identity through a private Python service built with FastAPI and OpenCV YuNet and SFace.

This separation makes the trust boundary explicit: the browser or device sends an attempt, the biometric service returns verification information, and the application server decides whether attendance can be finalized. A successful face comparison alone does not override scheduling, eligibility, or duplicate-attempt policy.

• RFID supplies the expected student identity.
• A short-lived verification transaction connects the attempt to its expected subject.
• The private verifier performs the 1:1 facial check.
• The server combines verification with attendance-session and authorization rules.

Retries should not create duplicate attendance

Device networks are imperfect. A scan request can time out after the server has already processed it, and the sender may retry without knowing the earlier outcome. An attendance system must distinguish a retry of the same operation from a new event.

The project uses an atomic, idempotent attendance-finalization path to prevent repeated submissions from writing duplicate attendance. The important design lesson is that the uniqueness and finalization rules belong at the persistence boundary, not just in button disabling or an in-memory client flag.

Failure feedback is part of the security design

A camera that fails to obtain a usable face is not the same event as a confirmed identity mismatch. Conflating these conditions would make device feedback misleading to staff and students.

The documented hardware contract distinguishes accepted verification from proxy-attendance rejection, including different LED and buzzer feedback. No-face and poor camera-quality cases are intentionally treated separately. That distinction gives operators a more actionable signal without presenting every sensor failure as an accusation.

What the implementation demonstrates

The project connects a Next.js application, PostgreSQL and Supabase data policies, role-based staff workflows, a private FastAPI verification service, and device-facing APIs. Reports are derived from canonical attendance data rather than independent client counters.

The source repository documents the system boundaries, RFID and camera behavior, server authorization, and test coverage in Vitest and pytest. The implementation is useful as a reference for designing trustworthy hardware-assisted workflows, not as a claim that biometric matching is infallible.