Context
This is a portfolio architecture case study, not a claim about a deployed client system. It demonstrates how I would turn an operational requirement into a supportable business application.
Business problem
Paper registers and shared spreadsheets make access records slow to reconcile and difficult to audit. Operators need a quick check-in flow without exposing personal information in a QR code.
Users and roles
Visitors need a fast check-in; reception staff need clear status feedback; authorised administrators need reporting and exception handling; support teams need traceable diagnostics.
Requirements
- Keep personally identifiable data out of QR payloads
- Support role-based access and revocation
- Provide a clear audit trail
- Remain usable on small mobile screens
- Degrade safely during temporary connectivity problems
Solution
The proposed flow exchanges a short-lived opaque token for a server-side access decision. A React interface gives staff a focused scan-and-confirm experience, while an ASP.NET Core API owns authorisation, validation and audit events.
Technology
Implemented or actively explored
- ASP.NET Core
- React
- PostgreSQL
Planned for a future version
- Azure
- OpenID Connect
Proposed architecture
A server-rendered web shell loads the scanner only when required. The API separates identity, access policy and reporting modules. PostgreSQL stores transactional data; append-only audit events support investigation without becoming the operational source of truth.
Security considerations
- Short-lived, single-purpose QR tokens
- Least-privilege roles enforced in the API
- Rate limiting and replay detection
- Encrypted transport and managed secrets
- Retention rules for access and audit records
Accessibility considerations
- Keyboard-operable administration flows
- Status communicated with text and icons, not colour alone
- Clear focus order and error summaries
- Touch targets sized for reception tablets and phones
Key decisions
- Prefer online authorisation for final access decisions
- Use opaque tokens rather than encoded personal data
- Log decision reasons without recording unnecessary sensitive data
- Keep recovery workflows explicit for support staff
Trade-offs
- Online authorisation improves revocation accuracy but depends on connectivity
- Detailed audit events aid support but require strict retention and access controls
- A focused scanner interface reduces errors but moves advanced controls into separate administration screens
Current status
This project is currently labelled Architecture case study. It is not presented as a live client deployment.
Challenges
The central trade-off is speed versus assurance. A scan must feel immediate, but cached or offline decisions can become unsafe when access is revoked.
Outcomes and measurement
The design produces a testable boundary between identity, policy and the user interface. Success would be measured with check-in completion time, failed-scan reasons, support volume and audit completeness after a real pilot.
Lessons learned
Operational exceptions deserve first-class design. Expired codes, duplicate scans and temporary outages need understandable recovery paths, not generic error messages.