Hardware Leasing & Slot Arbitration: Managing 15-Minute Dedicated Printer Windows

The Single-Tenant Hardware Constraint

Most web applications deal with stateless, horizontally scalable resources. If 1,000 customers request a web page, additional container instances spawn to service the load.

Physical hardware cannot scale horizontally on a single customer's order. A high-resolution 6-color dye-ink photo printer like the **Epson L8050** takes between 45 and 90 seconds to deposit microscopic ink droplets on a single 260 GSM photo card. If two customers were able to trigger jobs simultaneously, either: - The print spooler would interleave pages, mixing one customer's private memories with another's. - Or a technician would have to intervene to pause, sort, and organize the physical output, destroying the zero-knowledge privacy guarantee.

Therefore, our system treats every physical printer as a **strictly single-tenant, mutex-locked resource**.

15-Minute Slot Architecture

We partition printer availability into precise 15-minute intervals across operational hours: `10:00–10:15`, `10:15–10:30`, `10:30–10:45`, and so on.

A 15-minute duration is calibrated to allow the customer: 1. Up to 5 minutes to connect their secure session token, inspect files in browser memory, and adjust paper finishes (Matte vs. Gloss). 2. Up to 8 minutes for the Epson Micro Piezo print head to execute the bi-directional photographic raster pass across the entire pack. 3. 2 minutes for mechanical sheet ejection, head parking, and buffer zeroization.

[15-MINUTE SLOT TIMELINE]
00:00 ──────────────── 05:00 ──────────────── 13:00 ──────────── 15:00
  Session Connected      User Clicks PRINT      Print Complete      Buffer Wiped
  Browser RAM Ingest     Hardware Raster Pass   Tray Ejection       Slot Released

Preventing Race Conditions: Two-Phase Slot Reservation

When multiple users browse the booking calendar, two users could click the exact same time slot at the same millisecond. To prevent double-booking without blocking read throughput, we implement a two-phase reservation protocol in PostgreSQL using Prisma transactions:

// Atomic slot reservation with 10-minute checkout timeout
const result = await prisma.$transaction(async (tx) => {
  const slot = await tx.slot.findUnique({
    where: { id: Number(slotId) },

if (!slot || !slot.isAvailable) { throw new Error('Slot is no longer available'); }

const now = new Date(); // Check if another customer is currently checking out this slot if (slot.reservedUntil && new Date(slot.reservedUntil) > now) { throw new Error('Slot is currently locked by another customer in checkout'); }

// Soft-lock the slot for 10 minutes to allow payment completion const reservedUntil = new Date(Date.now() + 10 * 60 * 1000); await tx.slot.update({ where: { id: slot.id }, data: { reservedUntil }, });

// Create order linked to slot return await tx.order.create({ data: { slotId: slot.id, product, finish, quantity, pricePaise, status: 'CREATED', token: crypto.randomUUID(), }, }); }); ```

Autonomous Slot Reclamation

If a user abandons checkout or encounters a payment issue, the slot lock must automatically decay so that other customers can book it.

We run an automated background monitor service (`scripts/slot-monitor.js`) using a non-blocking cron interval: - Finds all slots where `isAvailable = true`, `reservedUntil < NOW()`, and no paid order exists. - Resets `reservedUntil = null` in bulk. - If a paid order reaches the end of its 15-minute printing window, marks the session `EXPIRED` and releases the physical hardware to standby state.