Rebuilding counter ticketing for Bangladesh's largest travel platform

Launch (ferry) tickets have a quirk: a single physical seat on a long-haul route can legally be sold twice when passengers board and alight at different points (Passenger A: Dhaka → Barisal, Passenger B: Barisal → Chittagong — same seat, same boat, two PNRs).

No competitor supported it. Legacy systems blocked it as a "double booking." We modeled seats as segmented inventory — each seat is a graph of boarding → alighting edges, availability computed per-segment, not per-seat. A booking consumes only edges it traverses.

Frontend renders the same seat as bookable or blocked contextually based on the counterman's selected origin–destination pair.

Two countermen clicking the same seat simultaneously during Eid rush was routine. Initial approach (API availability check → book) produced double-bookings in prod.

• →Pessimistic DB lock on seat-segment rows during commit transaction — guarantees correctness.
• →WebSocket broadcast of seat state changes to all connected counters — cuts race window to milliseconds, gives real-time UX (seat turns red on every screen the instant someone grabs it).
• →20-min hold TTL on in-progress carts, auto-released via background job.

Ferry terminals lose connectivity for hours. Tickets still have to print. Built:

• →Local IndexedDB cache of seat inventory + fare rules, synced on connection.
• →Optimistic booking queue — counterman prints challan offline, transaction replays on reconnect.
• →Server-side reconciler detects offline overlap, surfaces to ops for manual resolution (<0.1% of cases).

A counterman routinely books 10–200 seats per transaction — family groups, corporate charters, Eid migrations. UX had to let them:

• →Select non-contiguous seats across multiple rows with keyboard + click.
• →Assign different passenger info per seat (name, phone, age, gender — gender-segregation rules enforced).
• →Mix boarding / alighting points across tickets within same transaction.
• →Split payment: cash + bKash + card on one invoice.
• →Commit atomically — all seats book or none do.

Built as a multi-step cart with live fare recomputation via WebSocket-bound state.

Every operator has its own pricing: peak multipliers, student discount, senior citizen rules, seat-class premiums, route surcharges, counterman commission tiers, platform commission. Legacy was hardcoded. Modeled as a rules engine — operators configure fare matrices via admin panel, engine computes at booking time. Frontend shows live breakdown so countermen can explain to passengers on the spot.

Each operator's legal challan had its own template — column order, logo placement, tax ID positioning, regulator-mandated fields (BRTA / BIWTA). Built a template renderer that compiles ESC/POS commands per operator and streams to thermal printers over USB / network, with print retries and jam handling.

Partial refunds on segmented seats — refund one leg of a multi-segment booking without disturbing the other. Cascading rules: time-to-departure tiers, operator policy, payment-method rollback (wallet instant, card via PG, cash via counter).