60M+
Events processed per day
Case study · Internal Product
Multi-Tenant Retail Data Platform Serving 4 Mid-to-Enterprise Brands
Four retail brands wanted the same answer — what's actually happening across my channels right now — but each had a different stack (Shopify, SAP, NetSuite, custom).
Rust
Apache Airflow
PostgreSQL
Snowflake
PyTorch
KubernetesProject details
- Client
- Multi-tenant Destm-built data platform (4 brand tenants)
- Industry
- Internal Product
- Services
- Data Platform · AI / ML · Product Engineering
- Timeline
- 18 months from first tenant to fourth tenant
- Year
- 2025
The challenge
What we walked into.
Four mid-to-enterprise retail brands wanted the same answer — what is actually happening across my channels right now. Each had a different stack: one on Shopify Plus, one on SAP, one on NetSuite + Magento, one on a custom Rails monolith. Building a one-off pipeline per brand would have been a 4-year forever-engagement.
The economics demanded one platform, not four. But multi-tenant retail data is hard — every brand has its own SKU taxonomy, its own returns logic, its own definition of a refund vs. a chargeback. Naive multi-tenancy collapses into a thin schema that pleases nobody.
We had to build for tenant isolation at the data layer (no brand sees another brand's anything) while sharing infrastructure, ML models, and operational tooling. Plus retail-grade SLAs — sub-second freshness on hot-path metrics like inventory and orders, 5-minute SLA on analytical metrics like attribution.
What we built
The engineering decisions.
Hot-path / cold-path split
The hot path — orders, inventory, returns, refunds — lands in a per-tenant Postgres within 500ms of source-system event. Built in Rust for memory safety and low-latency event processing. The cold path — historical aggregation, attribution, cohort analysis — flows nightly into per-tenant Snowflake schemas. Two paths, two SLAs, no compromise.
Tenant-isolated, infra-shared
Each tenant gets their own Postgres database and Snowflake schema — total data isolation, separate encryption keys, separate audit logs. The shared layer is the orchestration (Airflow), the model serving (a gRPC service), and the operational tooling. One on-call rotation for 4 tenants, not 4.
Shared models, fine-tuned per tenant
Stockout prediction, channel attribution, and basket-affinity models are trained once on cross-tenant data (anonymized, opt-in) and fine-tuned per tenant on their own data. Every tenant gets the lift of the cross-brand signal without leaking data between them.
Onboarding velocity as the metric
First tenant took 6 weeks to onboard. We tracked every hour of that 6 weeks, found the connectors and the schema-mapping work that would repeat per tenant, and built tooling for the repeat work. Fourth tenant took 4 days. This platform became the engineering precursor to MetriQ, our productized AI metrics layer.
The results
Measured outcomes.
- 60M+ events processed per day across 4 tenants
- Sub-second freshness on hot-path metrics; 5-minute SLA on analytical metrics
- Shared infra cost ~30% of what 4 single-tenant builds would have cost
- Tenant onboarding time dropped from 6 weeks (first tenant) to 4 days (fourth tenant)
Next case study
Engineering Deep-Dive: How Destm Built CuberiQHave a similar challenge?
We'd love to hear about it. Every conversation starts with a senior engineer who's built systems like yours.