Pedalen bike rental: how a rental works · example · invented shop

Pedalen rents bikes by the hour, and every rental, from the web, the counter or a hotel voucher, passes one reserve() door that writes the row everything else reads.

This page shows how a rental starts and what it touches. Read it top to bottom: each section asks one question, draws the answer, and says what it means for the shop.

01

Figure 1 · the rental machine · every way in passes one door

Where does a rental start, and what does every way in share? Look at the dashed line: above it, one adapter per way in; below it, the parts every rental passes.

Figure 1 · the rental machine · every way in passes one door

ABOVE THE LINE — ONE ADAPTER PER WAY IN BELOW THE LINE — SHARED BY EVERY WAY IN WAYS IN · 4 web booking picks bike + hours counter walk-in, staff types hotel partner nightly voucher file mobile app missing, planned THE CORE · 3 one door, one writer reserve() checks, holds, writes availability free bikes per hour rental the row everyone reads THE FLEET · 3 bike frame no, status bike model city, e-bike, cargo smart lock code per rental MONEY · 3 payment card, at reserve deposit held, released at return refund manual today HOW TO READ the door · only writer of a rental reads or calls missing, drawn where it would sit 1 2 3

Above the line, one adapter per way a rental starts; the app is missing and drawn dashed in the slot it would fill. Below the line, everything is shared: one reserve() door writes the rental, which holds a bike and a payment.

  1. The only writer. Web, counter and hotel all call it; it checks the bike is free and writes the rental.
  2. Batch, not live. Vouchers arrive in a nightly file, so a guest booked today rides tomorrow unless staff retype it.
  3. Missing. Drawn in the slot it would fill; it would call reserve() like the web shop.

Every way in ends at reserve(), so a new channel is one more adapter, not a second booking system. The weak spot is the hotel voucher file, which arrives once a night; the next section shows what a rental writes when it gets through.

02

A rental is reserved, then unlocked

What happens between a click on the web shop and an open lock? Read the five actors left to right and the steps top to bottom.

A rental is reserved, then unlocked

A rental is reserved, then unlockedThe rider picks a bike on the website. The site charges the deposit with the payment provider, then in one transaction checks the bike is free, writes the rental and the payment, and commits. After commit it asks the lock service for a code and texts it to the rider. At the rack, the rider enters the code and the lock opens.pick bike and hourscharge depositapprovedlock bike rowcheck bike is freeinsert rental + paymentcommitcreate code for rentalcode 4 digitssms with codeenter code at the racklock opensONE TRANSACTIONRiderWeb shopPaymentsDatabaseLock service
person / consentboundary / logicexternal systemstored recordinventory / supply

Read top to bottom. The pale band is one database transaction: the card is charged before it opens, so the transaction never waits on the payment provider. The lock code is sent after commit.

  1. Charge first. The deposit is approved before the transaction opens, so it never waits on the provider.
  2. One transaction. Lock the bike row, check it is free, insert rental and payment, commit.
  3. Code after commit. A failed commit leaves no lock code behind.

The card is charged before the transaction and the lock code is sent after it, so neither outside service can hold a rental half-written.

03

The rental data model, six tables

What does the shop store, and how do the tables join? Start at rental, the row everything else reads.

The rental data model, six tables

The rental data model, six tablesA customer has many rentals. A rental holds one bike and has one or more payments. A bike is of one model. A rental can have damage reports, which are planned and not built.customer_idmodel_idbike_idrental_idrental_id, plannedcustomeruuididPKtextphonematch key for smstextemailbooleanopted_outrentaluuididPKuuidcustomer_idFKuuidbike_idFKtimestamptzstarts_attimestamptzdue_attextstatusheld, out, returned, latebike_modeluuididPKtextkindcity, e-bike, cargointprice_per_hourNOKbikeuuididPKuuidmodel_idFKtextframe_notextstatusready, out, repairpaymentuuididPKuuidrental_idFKtextkindcharge, deposit, refundintamountNOKdamage_reportuuididPKuuidrental_idFKtextphoto_path
person / consentstored recordinventory / supplycomputed / processingblocked / failed

What exists and how many: a customer has rentals, a rental holds one bike and its payments. Damage reports are planned and not built.

A rental holds one bike and one or more payments, so deposits and refunds are rows, not edits. Damage reports have no table yet; adding one is a single join on rental_id.

04

Season prep, the week before opening

What has to happen the week before opening, and what holds it up? The red bars are the critical path.

Season prep, the week before opening

Season prep, the week before openingFleet work runs Monday to Wednesday, with the e-bike service and the lock firmware update on the critical path. The website and the hotel partner deals run alongside. Opening day is Saturday.service city bikesservice e-bikeslock firmware updatenew prices on the websitehotel partner vouchersopening dayFleetSalesOpeningMon 05Tue 06Wed 07Thu 08Fri 09Sat 10Sun 11

What runs when on a calendar. The red bar is the critical path: the e-bikes cannot go out before the lock firmware is updated.

Nothing else in the week can delay opening; the lock firmware can. If it slips past Wednesday, the e-bikes, a third of last season's rentals, open late.