Real-time data platform use cases built on the post-transaction query — the balance, position, or account view a user checks right after they act, that must reflect what just happened. What breaks when that derived view is served from a pipeline behind the transaction, under concurrency.
TL;DR: The hardest thing a real-time data platform has to do isn’t a dashboard that refreshes fast — it’s the post-transaction query: a user executes a trade, transfer, or deposit, then immediately checks the derived view that must reflect it. In a composed stack that view is a prepared aggregation lagging the transaction, and the full picture — balance, history, positions — is stitched from systems (ClickHouse, Redis) that were never consistent at one moment. Under concurrency the lag and the divergence both widen, so the user sees a balance that doesn’t reflect what they just did — and the team quietly softens the freshness SLA and tells users to refresh. This is part of our Decision-Time Use Cases series — real-time data platform decisions where a Context Lake serves raw and derived context under one consistent snapshot at the moment the query runs. Proof: a top-tier crypto exchange runs its entire Web3 wallet backend — portfolio, asset discovery, risk scoring across 60+ sources — on Tacnode, with subsecond reactivity replacing minutes of lag.
A real-time data platform use case is a post-transaction query the product must trust the moment after the user acts — a balance after a deposit, a position after a transfer, an account state after a settlement — inside the session, under concurrency. When the derived view is a prepared aggregation lagging the transaction, and the full picture is assembled from systems that were never consistent at one moment, the user sees state that doesn’t reflect their last action. A Context Lake serves the raw record and the derived view under one snapshot, so the query reflects the transaction that just committed beside it.
Each use case below is the same gap on a different surface. The validity window is the moment after the transaction — the user is still in the session, still looking. A result that doesn’t reflect their last action isn’t just stale; it has concrete business consequences: a support ticket, a lost trade, a decision made on a number that was already wrong.
A user executes a trade or payment and immediately opens their portfolio. The view has to reflect what just happened, subsecond. When it’s a prepared aggregation maintained behind the transaction, the balance lags the last few actions — and under concurrency, many users transacting and querying at once push the lag wider exactly when it’s most visible.
A Context Lake keeps the portfolio aggregate coherent as transactions stream in and serves it under one snapshot, so the balance the user sees already reflects the trade they just made — not the one the roll-up last saw.
An account view checked right after money moves — a deposit posted, a transfer sent, a settlement cleared — must reflect it. When the derived account state is reconstructed in a pipeline, the user sees funds that haven’t updated, or an available balance that still counts money already gone. It’s the same freshness gap the whole series turns on, on the account surface.
A Context Lake maintains account state sub-second as the events arrive, so the view reflects the money that just moved — and any downstream check reads the same current figure.
A complete position, holdings, or entity view — a portfolio, a wallet, a customer 360 — needs several retrieval patterns at once (point lookups for balances, scans for history, aggregations for exposure) drawn from many upstream systems, each with its own freshness. Split across Redis for lookups and ClickHouse for scans, the paths drift; the more sources feeding the view, the more moments it spans, and the composed picture reflects a state that never coexisted.
Because a Context Lake holds state in hybrid row/columnar tables and serves every source under one snapshot, the lookup and the scan hit the same current state — positions, history, and exposure resolve into one coherent picture. This is the production proof point: a top-tier crypto exchange serves its unified Web3 wallet view — portfolio, asset discovery, risk scoring across 60+ data sources — subsecond on Tacnode.
A platform that ingests disparate per-customer sources and serves real-time decisions back — monitoring, scoring, alerting across many tenants — has the context gap multiplied by tenant count. Each customer’s derived signals are prepared by a pipeline, and under concurrent decisions across tenants the prepared context lags the events feeding it, so a decision fires on a picture that predates the last few.
A Context Lake ingests each tenant’s sources and maintains the derived signals coherently, so a real-time decision for any tenant reads context that already reflects that tenant’s most recent events — one system serving many tenants under one consistent model.
Often the post-transaction view isn’t for a human — it’s read by the next automated step: a decision, a webhook, a workflow that acts on the derived state a prior write produced. When that read lags the write, the downstream action runs on a picture that doesn’t include what just happened, and two steps in the same flow see two different versions of reality.
When a Context Lake owns the derived state a decision writes back, the write commits under ACID and the next read reflects it — so the downstream action reads the state the prior step just produced, not a lagged copy. This is the coherence under concurrency the composed stack can’t guarantee across systems.
A real-time data platform isn’t held back by how fast it can scan — it’s held back by whether the balance, position, or account view a user checks right after they act reflects what they just did. Post-transaction balances, account state, unified positions and entity views, multi-tenant decisions, and downstream automated steps all fail the same way when the derived view lags the write, and all hold when raw and derived context are served from one coherent system.
A Context Lake keeps that state current and consistent for every query at once — so the view reflects the transaction beside it, and “reflects your last action” is a guarantee the product can keep under load.
Former Cockroach Labs. Tells stories about infrastructure that actually make sense.
Book a demo and discover how Tacnode can power your AI-native applications.
Book a Demo