The reporting store vs. the transaction store

Every payment platform starts with one database that serves both operational (authorization, capture) and reporting (merchant dashboards, analytics) queries. Every mature payment platform eventually splits them. The interesting question is when and how.

Written September 2025 from platform architecture reviews.

Why the split happens

• Different consistency requirements. Authorization needs strict consistency; reporting can tolerate eventual consistency by minutes.
• Different query shapes. Operational reads are point lookups; reporting reads are aggregates.
• Different scaling axes. Operational writes scale with transaction volume; reporting reads scale with merchant count.
• Different cost profiles. The operational store gets the fast, expensive infrastructure; the reporting store gets the cheaper, larger storage.

Where the split goes

• Transaction store: point-of-truth for the transaction lifecycle. Every event, every state transition, in strict order.
• Reporting store: projections optimized for merchant and internal queries. Aggregates, denormalizations, partitioning by merchant and date.
• A stream between them. Ideally the same event stream the transaction store publishes; the reporting store subscribes and materializes.

How to build it

• Start with the transaction store publishing events. Even if you're not splitting yet, the event stream is the future integration point.
• Introduce the reporting store as a subscriber. Materialise the projections the dashboards actually need; ignore the ones nobody uses.
• Migrate dashboards one at a time. The transaction store keeps serving the last few for months while confidence builds.
• Reconciliation runs against both. If the reporting store drifts from the transaction store, the reconciliation catches it before a merchant does.

The split is unglamorous work. It moves scaling headaches off the critical path and into a place where they're solvable.