1 — Flex Programs
What it is: The top-level configuration container for a Flex store. Everything a team configures — how fans pick events, how packs are structured, what pricing is used — hangs off a program.
2 — Base Inventory Definition
What it is: The raw tables that hold a faithful copy of vendor seat/price data. Built by polling the vendor API every ~20 minutes. No business logic here — just shaped vendor data, same format regardless of which vendor it came from.
3 — Inventory Snapshots
What it is: A pre-computed cache of suite availability per event, rebuilt every ~5 minutes by a cron job. The home page reads this instead of recomputing pricing on every request.
4 — Base Configs
What it is auth token lifetimes, timezone. Stored as JSONB per key, with an audit history table.
5 — Flex Frontend Configs
What it is: A data dump of UI settings and language strings for each Flex program. The backend stores and returns it; it does zero validation on the content. The frontend owns all type enforcement.
6 — Account Groups & Ledgers
What it is: how account groups and ledgers are represented — neither is a standalone tbl_*
7 — Suite & Section Mapping
What it is: Venue master data — how sections are configured for display, how suites are defined, and how partial suite sales work. None of this is per-event; it's defined once and applies to all events at the venue.
8 — Venues & Maps
What it is: Venues are mostly cosmetic — they exist to hold maps. A map attaches to a venue, and an event links to a venue so the right map loads.
9 — Events
What it is: An event is a game or show that can be purchased. Events are global — not scoped to any program. Programs reference events; suites are checked against events at query time.
0 — Tags
What it is: A lightweight, cross-entity labeling system. One tag can be applied to many different entity types — events, packs, tiers, packages, sections, price codes.
1 — Assets
What it is: Centralized image (and eventually video/PDF) storage. Assets are uploaded to S3/CloudFront by the admin project; this backend just stores the URL and maps it to entities.
2 — Notification Configs
What it is: Per-program settings that control which notifications fire and how they're configured. The purchase flow uses three keys (below), each enable/disable-able independently; NotificationKey also defines six payment_plan_* keys (reminder/success/failure × text/email) that use this same table but are dispatched by Cortex.
3 — Users
What it is: Fan account data — profile, sessions (JWT), account group membership (gating), credit balance, and card token. The last two are wired but not active yet.
4 — Payment Plans
What it is: Lets a fan pay for an order in installments over time instead of all at once. Two