Skip to content

Part 1 of 7 · Parking permit issuer series ~6 min read

A parking permit issuer on AWS for a few dollars a month

Sixty spaces, two hundred and forty staff, and a car park that is full by twenty past eight and half empty by three. Every proposal to fix it produces a stronger reaction than any other facilities decision, and the reason is that parking is one of the few workplace resources where the allocation is visible to everybody every morning.

an old brick building with a closed door
Photo by Justin Chae on Unsplash

Key takeaways

  • Over-issue deliberately, at a ratio derived from measured occupancy.
  • Publish the allocation rule before applications open. Which rule matters less than that.
  • Reclaim permits that go unused; they are the main source of new capacity.
  • Accessible bays are allocated on need and sit outside all of this.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: permits issued against spaces, allocated and reclaimedThree boxes across the top sit outside the AWS account. On the left, The car park with a fixed number of spaces. In the middle, Applications, more than there are spaces. On the right, Permit holders and everybody else. Each connects by an arrow to the AWS account container below. Occupancy flows down into the account. Who applied feeds in. Permits and a waiting list go back out. Inside the AWS account are three components in a row. On the left, The ratio: permits per space, derived from measurement. In the middle, Allocation by a published rule. On the right, Reclaim of permits nobody uses. A note at the bottom says none of these three is a technical problem and all of them benefit from being written down.AWS ACCOUNTThe car parka fixed numberof spacesApplicationsmore than spacesPermit holdersand everybody elseThe ratiopermits per space,from measurementAllocationa published ruleReclaimpermits nobody usesoccupancywho appliedpermits, and awaiting listNone of these three is a technical problem. All of them benefit from being written down.
Fig 1. Three things outside the account, three pieces inside it. The engineering is trivial; the value is in making each decision explicit and consistent.
  • Compute
  • Analytics
  • Front-end & mobile
  • People

Why this is hard

Not technically. A permit is a row in a table and a car park has a number of spaces in it. The difficulty is entirely that parking allocation is a visible distribution of a scarce good among colleagues, and any rule produces people who did not get one and can see who did.

Which means the design goal is not optimality; it is defensibility. A rule that is published before applications open, applied consistently, and shown to have been applied consistently, produces far less trouble than a better rule applied opaquely.

What runs (the inside)

  • The ratio. How many permits to issue per space, derived from measured occupancy rather than guessed. Part 2.
  • Allocation. The published rule, applied and recorded. Part 3.
  • Reclaim. Finding permits that are not being used and returning them to the pool. Part 4.

One year, end to end

One year of parking permit allocation in five stagesA horizontal row of five boxes joined by arrows. Sixty spaces with measured occupancy at seventy-one per cent. Ratio one point three five, giving eighty-one permits. Rule published before applications. One hundred and thirty-seven apply: eighty-one allocated and fifty-six waiting. Nine reclaimed by March. A note says the reclaimed nine are the single largest source of new permits all year.ONE YEAR, END TO END60 spacesmeasured occupancy 71%Ratio 1.3581 permitsRule publishedbefore applications137 apply81 allocated, 56 waiting9 reclaimedby MarchThe reclaimed nine are the single largest source of new permits all year.
Fig 2. The same system as one line. The last box produces more capacity than anything else available and costs nothing.
  • Compute
  • Analytics
  • Front-end & mobile

In plain words

Sixty spaces. Counting cars at ten in the morning for a month shows the car park averaging seventy-one per cent full when permits were issued one per space, which means roughly three in ten permit holders were not there on any given day.

So eighty-one permits are issued against sixty spaces, a ratio of one point three five. That is deliberately conservative — the arithmetic would support more — because being turned away when you have a permit is a much worse experience than not having one.

A hundred and thirty-seven people apply. The rule was published two weeks before applications opened, it is applied, eighty-one people get permits and fifty-six go on a waiting list with their position visible. By March, nine permits have been reclaimed from people who used them fewer than four times, and nine people move off the list.

Design rules that shaped every decision

  • Derive the ratio from measured occupancy, and re-derive it annually.
  • Publish the allocation rule before applications open. Every time.
  • Show waiting list position; an invisible list is assumed to be fixed.
  • Reclaim on measured usage, with warning, and a way to explain.
  • Accessible bays are outside the ratio, the ballot and the reclaim.
  • Never enforce automatically. Every enforcement action goes through a person.

Why this shape

The value of a system here is almost entirely in consistency and visibility. A spreadsheet managed by one person produces the same allocations and produces them in a way nobody can check, which is what generates the belief that permits are given out on the basis of who asks loudest.

Everything in this design is oriented at making the process checkable: a stated rule, a recorded application of it, a visible waiting list, and usage data that makes reclaim a fact rather than a judgement.

The next four posts walk through each piece: how many permits for how many spaces, how allocation gets decided, what happens to a permit nobody uses, and why enforcement is the hard part. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts