Design Vaccine Eligibility & Booking

Introduction

This prompt mixes marketplace inventory with policy engines and public trust. Weak answers treat slots as integers you decrement in the app layer without transactions. Strong answers add versioned rules, append-only audit, race-safe booking, and a spike story that is not “we autoscale to infinity.”

Governments and users remember wrong eligibility and double-booked vials more than your microservice diagram.

How to approach

Separate eligibility (read-heavy, cacheable with care) from booking (write-heavy, must be exact). Sketch the spike path: waiting room → signed token → transactional book. Always log rule_version on every eligibility decision.

Interview tips

• Client-trusted eligibility is a non-starter—evaluate on the server with the same rule version as the audit record.
• Last-slot races: use a unique constraint on (slot_id, user_id) or SELECT … FOR UPDATE on remaining inventory—mention both patterns.
• PII: minimize fields; encrypt at rest; redact logs; aggregate reporting without row-level export to unauthorized roles.
• Thundering herd: a waiting room is real backpressure—token issue rate should match booking capacity, not HTTP thread count.
• Bad rule deploy: freeze new bookings, rollback config, re-evaluate open sessions—playbook language scores points.

Capacity estimation

Dimension	Note
Concurrent users on cohort open	Orders of magnitude above steady state—admission control required
Slots per site	Hot sites contend on the same rows
Audit volume	Often retained longer than OLTP—separate store or partition
Reminder sends	Bursts before appointments—queue workers

Implications: protect the booking API with tokens; shard inventory by region or site; never fan out email synchronously on the booking critical path.

High-level architecture

Identity (or government IdP) establishes who is calling. The rules service loads versioned policy from a config store, evaluates eligibility from attributes (age, region, job codes), and returns decision_id, rule_version, and reason codes for support (no raw PHI in logs). Scheduling exposes slot search (read replicas or cache). Booking runs short transactions on slot inventory. An audit pipeline appends immutable records to WORM or append-only storage. Notification workers consume outbox events.

[ User ] --> [ CDN / static ] --> [ Waiting room edge ]
                    |
                    v signed admission token (rate limited)
[ Eligibility API ] --> Rules engine (versioned) --> decision + audit
        |
        v
[ Slot search ] --> read-optimized (may be slightly stale)
        |
        v
[ Book slot ] --> [ TX: decrement remaining OR lock row ] --> confirm
        |
        +--> outbox --> reminders / calendar / analytics (async)

In the room: Say clearly: HTTP 200/201 after DB commit; email later; inventory truth is not “SMTP accepted.”

Core design approaches

Rules as data

Version every deploy; shadow-evaluate before flipping traffic; rollback = moving a pointer to a prior config version.

Inventory

Either a remaining count per slot with CHECK (remaining >= 0) or one row per seat with a unique booking—second pattern is stronger against lost updates under concurrency.

Spike handling

The edge issues tokens at a fixed RPS so the origin sees smooth load; queue discipline (FIFO vs lottery) is a product choice.

Detailed design

Eligibility

1. User submits attributes (some verified externally).
2. Server loads rules_vN, evaluates, persists an eligibility_decision row with rule_version.
3. Cache decision reference in session with TTL; invalidate on rule bump if needed.

Booking

1. User selects slot id from search (may be stale).
2. POST /appointments with Idempotency-Key.
3. BEGIN: verify eligibility still valid for rule_version; lock slot row; ensure remaining > 0; decrement; insert appointment; COMMIT.
4. Return confirmation; notify asynchronously.

Key challenges

• Rule vs inventory consistency: user passed eligibility yesterday; rules changed today—re-check at book time.
• Double submit: idempotency keys and unique constraints.
• Bot traffic: CAPTCHA, per-IP limits, device signals, staggered cohort opens.
• Reporting: aggregate counts by region without PII exports—separate pipeline with RBAC.
• Provider integration: calendar sync is often async reconcile—the appointment row in your DB is source of truth.

Scaling the system

• Regional deployments for data residency; route global read traffic to nearest edge.
• Read replicas for search; primary for booking transactions.
• Partition the slots table by region_id or site_id.
• Autoscale workers on queue depth, not only CPU.

Failure handling

Scenario	Response
Rules service down	Often fail closed for new eligibility—or serve last known read-only decisions with a banner (product call)
Slot DB partition	Fail closed for booking in affected region
Notification failure	Appointment still valid; retry reminders; DLQ alert
Wrong rule published	Freeze; rollback; re-evaluate edge cases manually or in batch

API design

Endpoint	Role
POST /v1/eligibility:evaluate	Returns decision_ref, rule_version
GET /v1/slots	Search by geo and time window
POST /v1/appointments	Book; Idempotency-Key required
DELETE /v1/appointments/{id}	Cancel per policy

GET /v1/slots

Param	Role
lat, lng, radius_km	Geo filter
from, to	Time window
rule_version	Optional client hint—server still validates

Booking flow diagram:

POST /eligibility:evaluate --> store decision + rule_version
GET /slots (cached / replica)
POST /appointments + Idempotency-Key
       --> TX: eligibility still OK + slot lock + decrement
       --> 201 Created

Errors: 409 slot gone; 403 ineligible under current rules; 429 rate limit.

Production angles

High-stakes booking flows combine traffic spikes, policy engines, and inventory that must never go negative—while auditors expect a paper trail for every “no.” Production pain is rarely “the button failed”; it is waiting rooms that never issue tokens, double books under concurrency, and support staring at an opaque ineligible flag during a crisis.

National news spike: site “up,” nobody can complete a booking

What it looks like — Status page is green; edge serves HTML; users queue forever or bounce at token exchange. Origin RPS looks healthy because few requests make it past admission control. Social feeds fill with “system is broken” while your p95 API latency is fine for authenticated paths that never fire.

Why it happens — Waiting-room or token bucket misconfiguration: tokens/sec too low, clock skew between edge and origin, HMAC verification failing under key rotation, or feature flag accidentally requiring a header only new clients send. Load tests often skip the full browser path.

What good teams do — Dashboards on token issue rate, validation failure reasons (signature vs expiry vs scope), and end-to-end funnel from queue exit to appointment row. Runbooks with feature-flag bypass for verified cohorts when policy allows—ethics and legal pre-approved. Seniors treat admission control as a first-class service with SLOs, not a CDN add-on.

Inventory goes negative or double-booked under load

What it looks like — Support finds two confirmations for one slot; DB constraints fire in logs; or worse, no constraint and negative remaining counts. Postmortems mention Black Friday patterns even for public-health scale.

Why it happens — Read–modify–write in application code without serializable boundaries; optimistic locking with retry storms; cache of “slots left” that lies. Idempotency keys prevent duplicate charges but not duplicate locks if scope is wrong.

What good teams do — Single transaction (or one authoritative row per slot) that decrements only if count > 0; unique constraint on (slot_id, user_id) where business allows; postmortem on every negative row—no normalization as “edge case.” Reconciliation jobs for orphan holds vs payment state.

“Why was I denied?” — Support and regulators need an answer

What it looks like — User is angry; journalist calls; ombudsman request. Your audit log says eligible: false with no branch detail. Engineers grep rule engine versions manually.

Why it happens — Product shipped fast with boolean eligibility; rules composed in code without persisted decision records; PII concerns led to over-redaction.

What good teams do — Structured reason codes and rule_version on every evaluation; explain object per branch (not raw PHI in logs—hashed inputs + code references); immutable append-only audit with tamper evidence where required. Seniors separate what we show the user from what we retain for compliance.

Spike diagram: where the funnel actually breaks

What it looks like — Queue wait SLO red while origin CPU is blue. That pattern means misplaced bottleneck.

[ News spike ] --> edge tokens/sec capped --> origin RPS flat
                        |
              queue wait time SLO monitored

What to measure — Token issue vs validate success; booking transaction latency and conflict rate (409); audit write lag; rule evaluation errors by version. Correlate queue depth with geography—CDNs can mask regional token failures.

How to use this in an interview — Lead with concurrency on slots and explainability of policy—not just REST. Close with audit: what you would show an ombudsman after a bad deploy—rule_version, hashed decision inputs, not a clipboard of raw PHI.

Bottlenecks and tradeoffs

• Fairness vs velocity: lottery for slots vs FIFO—political product choice.
• Stale search vs fresh booking: honest UX copy reduces support tickets.