Engineering case study · Azure · 2026

Designing a simpler registration flow for very high demand.

I designed and built a serverless pre-registration platform with Azure Functions, Table Storage, Key Vault, HTMX and TypeScript. The goal was not to reproduce an existing ticketing system, but to test whether a narrower registration problem could be made simpler, safer and easier to scale.

Live demo View source code View measured results

This demo, including its frontend, runs on an Azure server that scales to zero when idle. The first visit after inactivity may take longer while the server starts up.

126,124 successful registrations in a five-minute test run

0 failed HTTP registration requests in the published run

634 ms p95 response time calculated from the published results

01 · Problem

Reduce the synchronous work before trying to scale it.

The public Amsterdam 750 ticket release showed a familiar failure mode: large numbers of visitors waiting for access to a scarce downstream process. I used that situation as a starting point for a smaller engineering question.

What if pre-registration itself were a short, stateless operation? Instead of keeping a browser tied to a long-running queue, capture intent quickly, protect the data immediately, and move follow-up work out of the request path.

This case study deliberately isolates that registration problem. It is not a claim that the complete original ticketing chain can be replaced by this architecture.

02 · Design

Keep the browser simple and move elasticity into Azure.

Browser + HTMX

Native forms and server-returned HTML, with very little long-lived client state.

Public Function

Validation, anti-abuse checks, normalization and registration handling.

Table Storage

Encrypted records, hashed uniqueness controls and optimistic concurrency.

Key Vault

Key-encryption operations are separated from the data itself.

Queue + worker

Invitations and follow-up work are processed independently from the initial request.

The design choice I care about most is not “HTMX instead of React” or “serverless instead of servers”. It is matching the amount of system complexity to the actual problem.

03 · Security

PII protection is a system property, not an encryption checkbox.

Application-level encryption

Stored PII is encrypted with AES-256-GCM before it reaches storage.

Per-record data keys

Each data-encryption key is wrapped with a Key Encryption Key held in Azure Key Vault.

Separated privileges

Public registration and privileged administration/decryption responsibilities are split.

Defense in depth

Rate limits, anti-abuse controls, hashed uniqueness locks, RBAC, monitoring and data minimisation reduce impact when one layer fails.

Important limitation: encryption at rest does not help if an attacker gains a legitimate application path that is allowed to decrypt the data. The architecture therefore treats encryption as one boundary among several.

04 · Evidence

Performance claims should come with enough context to inspect them.

Metric	Published result
Virtual users	250
Test duration	5 minutes
Successful registration POSTs	126,124
Failed HTTP registration requests	0
Calculated throughput	420.57 req/s
p95 response time	634 ms

One load test is not proof of unlimited scalability. The published evidence is intended to make this specific run inspectable, including its method, assumptions and limitations. Read the load-test methodology.

05 · Review the work

The implementation is public as a separate sanitized code snapshot.

The source repository contains the public and admin Function Apps, the HTMX frontend, shared security code, tests and Bicep infrastructure source. It was exported without private Git history, local settings, production drift files or operational credentials.

Browse implementation Case-study repository