Two failures would have sunk it on day one, and customers notice both instantly:

1. two people booked into the same slot;
2. the same confirmation email arriving twice.

They look unrelated. They are the same bug: an operation that must happen exactly once, in a system where requests race and jobs retry.

Double-bookings: never trust what the browser last saw

Two clients open the page and both see 10:00 free. Both click Book. If availability is decided from what each browser last saw, both win.

So availability is computed on the server, from a single source of truth — the database — rather than from client state. Every check goes through the server; that is the price of removing the race.

Server-side is necessary, not sufficient: two requests can still pass the check at the same moment. The strongest place for the guarantee is the database itself. In PostgreSQL, an exclusion constraint makes overlapping bookings for the same resource impossible, no matter how the requests interleave (an illustrative schema, not the production one):

CREATE EXTENSION IF NOT EXISTS btree_gist;

CREATE TABLE bookings (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  resource_id bigint    NOT NULL,          -- a chair, a stylist, a room…
  during      tstzrange NOT NULL,          -- start/end as real instants
  status      text      NOT NULL DEFAULT 'confirmed',
  EXCLUDE USING gist (resource_id WITH =, during WITH &&)
    WHERE (status <> 'cancelled')
);

The losing request gets a constraint violation, which the app turns into "That time was just taken" and a fresh set of slots. No locks to reason about, no window to lose.

Duplicate emails: make every send idempotent

Transactional email jobs retry after timeouts — and a duplicate confirmation erodes trust fast. On Hearth & Hair, confirmations and reminders go through a queue, and every send is idempotent.

The key idea: derive an idempotency key from the business event, not from the attempt. Every retry of the same event produces the same key:

// One key per business event — every retry computes the same one.
const key = `booking:${booking.id}:confirmation`

const claimed = await db.query(
  `INSERT INTO sent_messages (idempotency_key, status)
   VALUES ($1, 'sending')
   ON CONFLICT (idempotency_key) DO NOTHING
   RETURNING idempotency_key`,
  [key],
)
if (claimed.rowCount === 0) return // already sent, or being sent

await mailer.send({ to: booking.email, template: 'confirmation', idempotencyKey: key })
await db.query(`UPDATE sent_messages SET status = 'sent' WHERE idempotency_key = $1`, [key])

Be honest about the gap: if the process dies between claiming and sending, that email never goes out. Keeping a status column lets a sweeper retry rows stuck in sending, and many transactional email APIs accept an idempotency key of their own — pass the same one. End to end, "exactly once" is really at least once, plus deduplication.

Reminders: time is the hardest input

The edge cases that needed the most iteration once real bookings flowed were about time: timezone handling, cancellation flows, and reminder timing. Three rules that hold up:

• Store instants, display local time. Keep timestamptz (UTC instants) in the database and convert to the business's timezone only when rendering.
• Key reminders by what they are about. Include the appointment's start time in the reminder's key — booking:42:reminder:2026-10-03T09:00Z. When a booking moves, the new time produces a new key, and the stale job is recognisably stale.
• Check before you send. A reminder job re-reads the booking right before sending and quietly exits if it was cancelled or rescheduled.

A checklist for "must happen once" operations

• Could two requests both succeed? What actually stops them — application code, or a constraint?
• If this job runs twice, what does the customer see?
• Is the idempotency key derived from the business event rather than the attempt?
• What happens to scheduled work when the thing it is about changes?

Putting the platform in front of real users surfaced edge cases no spec ever would have. The patterns above are what made those edge cases survivable.

These are the decisions that mattered, roughly in the order you will run into them.

1. Keep the bucket private

S3's public website endpoint is the quickest way to host files, and the wrong one here: it exposes the bucket directly and lets traffic skip the CDN. Instead, the bucket stays private and only CloudFront may read it, through Origin Access Control (OAC). The bucket policy grants read access to one distribution and nothing else:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontRead",
      "Effect": "Allow",
      "Principal": { "Service": "cloudfront.amazonaws.com" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::YOUR_BUCKET/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::ACCOUNT_ID:distribution/DISTRIBUTION_ID"
        }
      }
    }
  ]
}

2. Directory URLs need a rewrite at the edge

The catch with a private bucket: the S3 REST origin has no index documents. A request for /projects/neopark-smart-parking/ does not magically become index.html.

With trailingSlash: true, Next.js exports every page as <path>/index.html, so a tiny CloudFront Function on the viewer request completes the mapping — and redirects slash-less URLs, so each page has exactly one canonical address:

function handler(event) {
  var request = event.request
  var uri = request.uri

  // /projects/neopark/ → /projects/neopark/index.html
  if (uri.endsWith('/')) {
    request.uri = uri + 'index.html'
    return request
  }

  // /projects/neopark → 301 → /projects/neopark/
  if (!uri.split('/').pop().includes('.')) {
    return {
      statusCode: 301,
      statusDescription: 'Moved Permanently',
      headers: { location: { value: uri + '/' } },
    }
  }

  return request
}

3. The certificate lives in us-east-1

CloudFront only reads TLS certificates from ACM in us-east-1, whatever region your bucket is in. Request the certificate there, validate it through DNS, attach it to the distribution, and point Route 53 alias records for both the apex and www at CloudFront.

4. Split cache headers by how often files change

Fingerprinted assets never change; HTML has to reflect each deploy immediately. So the deploy syncs twice with different headers, then invalidates CloudFront:

# Fingerprinted assets: cache for a year
aws s3 sync out/ "s3://$BUCKET" --delete \
  --cache-control "public, max-age=31536000, immutable" \
  --exclude "*.html" --exclude "*.xml" --exclude "*.txt"

# Documents: always revalidate
aws s3 sync out/ "s3://$BUCKET" --delete \
  --cache-control "public, max-age=0, must-revalidate" \
  --exclude "*" --include "*.html" --include "*.xml" --include "*.txt"

aws cloudfront create-invalidation --distribution-id "$DISTRIBUTION_ID" --paths "/*"

One caveat: immutable is only safe for files whose name changes when their content does. Next's _next/static output qualifies; a hand-named cover.webp does not — when you replace an image, give it a new name. (This site's CMS content-hashes every upload for exactly this reason.)

5. Count visitors without a race condition

The obvious counter — read the count, add one, write it back — races when two visits land at once. A single DynamoDB UpdateItem with ADD does the increment atomically on the server:

import { DynamoDBClient, UpdateItemCommand } from '@aws-sdk/client-dynamodb'

const db = new DynamoDBClient({})

export async function handler() {
  const result = await db.send(
    new UpdateItemCommand({
      TableName: process.env.TABLE_NAME,
      Key: { id: { S: 'visitors' } },
      UpdateExpression: 'ADD #count :one',
      ExpressionAttributeNames: { '#count': 'count' },
      ExpressionAttributeValues: { ':one': { N: '1' } },
      ReturnValues: 'UPDATED_NEW',
    }),
  )
  return {
    statusCode: 200,
    body: JSON.stringify({ count: Number(result.Attributes?.count?.N ?? 0) }),
  }
}

On on-demand billing that is one hot item and no idle cost — plenty for a portfolio, behind API Gateway and a Node.js Lambda.

6. IAM is the real curriculum

Most of the friction in the whole project was IAM: OAC bucket policies, Lambda execution roles, and least privilege for the pipeline. Once those clicked, the other services felt like Lego.

For the deploy pipeline, give CI a dedicated identity that can touch this one bucket and this one distribution — nothing more:

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": "arn:aws:s3:::YOUR_BUCKET" },
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::YOUR_BUCKET/*"
    },
    {
      "Effect": "Allow",
      "Action": ["cloudfront:CreateInvalidation"],
      "Resource": "arn:aws:cloudfront::ACCOUNT_ID:distribution/DISTRIBUTION_ID"
    }
  ]
}

Better still, let GitHub Actions assume that role through OIDC instead of storing long-lived access keys as secrets: there is nothing to rotate and nothing to leak.

The result

From git push to live in under five minutes, for a monthly bill of a couple of dollars (domain aside). None of it is exotic — which is the point. The boring setup, done carefully, is the one that keeps working.

At Pertamina Patra Niaga (through my internship at Telkom Indonesia), the job was to flag missing helmets and vests across a facility's existing CCTV network. With Neopark, it was per-slot parking availability from low-cost ESP32-CAM boards instead of a sensor in every bay. Different problems, same lesson: production computer vision is roughly 80% data and infrastructure engineering.

Here is what that 80% looked like.

1. Assume every camera will let you down

Real camera networks are not benchmark datasets. The facility's NVR mixed heterogeneous RTSP streams, and some cameras simply dropped out. A naive loop — read a frame from each camera, run the detector, repeat — has a nasty property: one slow or stalled stream holds up detection for every other camera.

So ingestion and inference became separate concerns:

• every stream is read independently and normalised on ingest, so the detector only ever sees one frame format;
• flaky cameras get reconnection logic instead of taking the pipeline down with them;
• the detector consumes whatever frames are ready, so no single camera can stall monitoring.

It is more moving parts to operate than one loop. It is also the difference between a demo and a system that runs unattended.

2. Stabilise the output, not just the model

Neopark's early dashboard flickered: a parked car would read occupied, free, occupied across adjacent frames. Each frame could be "accurate" and the display still impossible to trust.

The tempting fix is a heavier model. The one that worked was a temporal smoothing layer on top of the detector: a slot only changes state once the new evidence holds for a short window. A minimal version of the idea (not the production code):

from collections import deque


class SlotSmoother:
    """Flip a slot's state only after the opposite state holds for `window` frames."""

    def __init__(self, window: int = 5) -> None:
        self.window = window
        self.state: dict[str, bool] = {}
        self.recent: dict[str, deque[bool]] = {}

    def update(self, slot_id: str, occupied: bool) -> bool:
        recent = self.recent.setdefault(slot_id, deque(maxlen=self.window))
        recent.append(occupied)
        current = self.state.get(slot_id, occupied)
        if len(recent) == self.window and all(seen != current for seen in recent):
            current = not current
        self.state[slot_id] = current
        return current

The trade-off: a slot flips slightly after the raw detection does. That is a small price for a display people actually believe.

3. Calibrate per camera, not globally

Lighting and viewing angles differ from camera to camera, so one global confidence threshold misjudged some bays while being fine for others. Two things fixed it:

1. training on a curated dataset that spans varied lighting, and
2. tuning thresholds per camera angle.

The cost is operational — every new camera needs a calibration pass before it goes live — so make that pass a documented step, not tribal knowledge.

4. Put the compute where it can breathe

ESP32-CAM boards are great frame sources and far too constrained to run a modern detector. Rather than squeezing the model onto the edge, Neopark keeps the edge thin and batches frames on a GPU-backed inference node, which held inference latency around 150 ms. The honest trade-off: the system now depends on the camera-to-server link, so that link deserves the same monitoring as the model.

5. Own the data, own the lifecycle

A detector has to perform on this facility's camera views, not on generic footage. For the PPE system that meant curating and annotating the dataset in-house, then training, deploying, and monitoring the model ourselves. The accuracy you can rely on comes from that loop far more than from architecture tweaks.

6. Ship something operations can run

The PPE system had to be handed over to the facility's operations team, so every service shipped as a Docker container. Neopark's stack runs in Docker for the same reason: deployments that are repeatable rather than hand-assembled.

A checklist before you call it done

• What happens when one camera stalls? When it disappears for an hour?
• Is the displayed state stable, or does it flicker from frame to frame?
• Can you add a camera without retraining — and is calibration written down?
• Where does inference run, and what happens when the link to it drops?
• Can someone else deploy and restart it without you?

When those answers are solid, the model usually is the easy part.