Pricing HQ: design shard-ready tenant routing for billion-item inventory #721

New Issue

2026-09-17T16:03:52Z

gambit-admin commented

2026-09-17 16:03:52 +00:00

Goal

Define and implement the operational data placement needed for up to 10 million accounts and approximately 1 billion inventory records.

Work

Use vendor ID as the tenant routing and data-placement key.
Separate globally shared market facts from tenant-owned strategies, inventory, prices and audit events.
Choose and document the near-term partition approach and the threshold for moving to multiple database shards.
Add a tenant-to-shard routing contract that does not leak infrastructure details into product APIs.
Ensure vendor transactions, inventory locks, pricing evaluation and checkout protection stay within one shard transaction.
Design hot-market-key fanout so a popular card can target inventory across shards without cross-shard database transactions.
Define online migration, rebalancing, backup, restore and tenant-move procedures.
Establish connection-pool and worker math per shard; coordinate with #651 and existing database pool work.
Add tests that reject cross-tenant and wrong-shard access.

Acceptance criteria

A vendor can be routed deterministically without scanning shards.
Shared market data is fetched once and distributed without duplicating provider spend per tenant.
Repricing and bulk jobs can resume across worker or shard failures.
Tenant movement has a documented rollback path.
The architecture includes measured scale thresholds, not only a 10-million-user label.

Dependencies: #715 and coordination with #651.

## Goal Define and implement the operational data placement needed for up to 10 million accounts and approximately 1 billion inventory records. ## Work - Use vendor ID as the tenant routing and data-placement key. - Separate globally shared market facts from tenant-owned strategies, inventory, prices and audit events. - Choose and document the near-term partition approach and the threshold for moving to multiple database shards. - Add a tenant-to-shard routing contract that does not leak infrastructure details into product APIs. - Ensure vendor transactions, inventory locks, pricing evaluation and checkout protection stay within one shard transaction. - Design hot-market-key fanout so a popular card can target inventory across shards without cross-shard database transactions. - Define online migration, rebalancing, backup, restore and tenant-move procedures. - Establish connection-pool and worker math per shard; coordinate with #651 and existing database pool work. - Add tests that reject cross-tenant and wrong-shard access. ## Acceptance criteria - A vendor can be routed deterministically without scanning shards. - Shared market data is fetched once and distributed without duplicating provider spend per tenant. - Repricing and bulk jobs can resume across worker or shard failures. - Tenant movement has a documented rollback path. - The architecture includes measured scale thresholds, not only a 10-million-user label. Dependencies: #715 and coordination with #651.