Engineering reference: the parking permit issuer architecture

The system, by service name

• Compute
• Database
• Networking
• Front-end & mobile
• People

Region and account

• Region: us-east-1. Chosen because SES inbound receipt rules exist in only a subset of regions and this one has the widest Bedrock model availability. If your data has to stay elsewhere, check both constraints before moving: inbound SES is the binding one.
• Account: one. This is a small system, and a separate account per environment costs more in wiring than it saves. A dev and a prod stack in the same account, with distinct resource prefixes, is the right size here.
• Everything is regional. The only global resources are the IAM roles and policies. There is no CloudFront, no global table and no cross-region replication, because nothing here has a latency or durability requirement that would justify them.

Lambda inventory

Splitting this into separate functions is not about modularity. It is that only one of them needs Bedrock permissions and only one is reachable from the public internet, and neither of those is true if it is one handler behind a router.

IAM, scoped

No role has a Resource: “*” on anything that writes, and every GetSecretValue grant names a single secret arn. That is why there is more than one secret rather than one JSON blob with everything in it.

DynamoDB schemas

Table: permits

PK   permit_id         S
     person_id         S
     vehicles          L   registrations; people change cars
     issued_at         S
     expires_at        S   annual, or the temporary end date
     kind              S   standard | temporary_need | accessible
     allocated_by_rule S   ’distance, 6.2km, above the 4.8km threshold’
     usage             M   {2026Q3: 41, 2026Q4: 3} — counts only
     review_state      S   none | asked | reason_given | releasing
     review_reason     S   the reason they gave, verbatim

`usage` holds counts, never dates. Storing which days somebody drove in
creates an attendance record collected for a different purpose.

Table: applications

PK   round_id          S   2026
SK   person_id         S
     applied_at        S
     distance_km       N   or whatever the published rule uses
     declared_need     S   free text, assessed by a person
     outcome           S   allocated | waiting | declined
     rule_version      S   the exact rule text published for this round
     tie_break_draw    N   recorded, because ties must be explicable
     list_position     N   shown to the applicant, and it moves

`rule_version` stores the published text, so a decision can always be
checked against the rule that was actually in force.

Inbound and outbound

• Applications open for a stated window after the rule is published, and the rule text is stored with the round rather than referenced.
• Usage arrives as increments, from whatever signal exists. The API accepts a permit and a date and stores only a counter.
• Accessible and temporary permits are a different kind and are excluded from the ratio, the ballot and the reclaim review.
• Waiting list position is computed from the stored ordering and shown to each applicant, including when it moves.

The model call

• There is no model in this system. Allocation is sorting and the reclaim ladder is four states.
• The tempting use is assessing declared need from free text. That is a judgement about somebody’s circumstances and it belongs to a person who can ask a follow-up question.
• The wrong use is number plate recognition and any inference from it. Part 5 covers what that record becomes.
• A defensible use is normalising vehicle registrations typed in different formats, which is a small annoyance solved more cheaply by a regular expression.
• The cost page assumes none, which is why messaging is the only variable.

That is the whole system. Seven posts, one diagram at a time, and nothing in it that needs a server.

All posts