Partner Capacity Is Not a CRUD (Create, Read, Update, Delete) Table (Partner Capacity Is Not A Crud Table)

Capacity is a voyage contract, not a shelf

Partner capacity lives with companies, vehicles, drivers, and discount rules. Flattening it to generic CRUD forces cancel and usage rules to be patched later.

Partner voyage capacity
   ├─ tickets (lifecycle)
   ├─ companies / vehicles / drivers
   └─ discounts (workflow)
          ↓
   Booking desk decisions

This series builds a ferry booking desk with domain and MFE boundaries.

Concepts, defined where they first appear

📦 Partner Capacity
Sellable/used capacity truth for a partner voyage.

📦 Booking Desk
Ops surface managing tickets and context.

📦 Lifecycle Field
A state field with transition rules — unlike plain CRUD.

📦 Partner Contract Leak
Contract-specific rules leaking into UI or reports.

Treating capacity as a table row gets expensive at cancel and billing time.

Where CRUD breaks

A sold ticket may cancel before use; it does not behave like stock decrement.

Context is mandatory

Without company-vehicle-driver, a ticket is meaningless.

Ticket → requires context graph

MFE boundary

The booking remote embeds in a shell and also runs standalone.

The mappings that get confused most often

❌ Ticket = product stock row
✓ Ticket = capacity right with a lifecycle

❌ Discount = price field
✓ Discount = approved workflow

❌ Show partner internals everywhere
✓ Block contract leakage in reports

A checklist for auditing your own system

1. Do you have a ticket transition diagram?
2. What side effects does cancel trigger?
3. Who must approve before a discount applies?
4. Who uses the standalone booking URL?
5. Any partner-specific language in report fields?

What to take away from this part

1. Partner capacity is lifecycle-shaped.
2. Context graph is part of the ticket.
3. MFE boundaries protect booking-desk speed.

Teams that treat capacity as CRUD treat cancel as DELETE.