Parking Lot

Use a ParkingService with replaceable allocation and pricing policies, a repository that atomically claims spots, and a ticket lifecycle that supports idempotent payment and exit.

1. Represent VehicleType, SpotType and TicketStatus explicitly. Encode compatibility in one policy, such as motorcycles fitting motorcycle/car spaces and trucks requiring truck spaces.
2. AllocationStrategy returns ranked candidates. In a repository transaction, conditionally claim a still-available compatible spot and create its active ticket. Retry another candidate if a concurrent request won the spot.
3. On exit, compute and persist a price quote. Transition ACTIVE → PAYMENT_PENDING using a stable payment key; retries use the same frozen quote and logical payment identity.
4. Call a payment gateway adapter outside the database transaction. A timeout leaves PAYMENT_PENDING for reconciliation; it must not trigger a second charge with a fresh key.
5. After confirmed payment, use one transaction to close the ticket and release its owned spot. Duplicate requests return the stored receipt. Handle lost tickets through a separate audited lookup and pricing policy.

• Two arrivals compete for one spot: exactly one ticket is issued.
• An incompatible vehicle cannot claim a spot even when it appears in a stale candidate list.
• Duplicate exit requests return one receipt and release only the ticket’s owned spot.
• Payment failure keeps the spot occupied; a payment timeout is reconciled without double charging.

Trade-offs to explain

• Composition allows allocation/pricing changes without adding a subclass for every combination.
• A local mutex is sufficient only for a single process. Multiple service instances require a shared atomic claim, such as a conditional database update.
• Exactly-once charging depends on gateway idempotency and reconciliation. Model ambiguous results explicitly.
• Persist currency and use integer minor units or a decimal type for prices. Define rounding and lost-ticket rules.