The Decision-Time System Model

The Shift

Before AI systems started making decisions, real-time infrastructure had a clear job: make metrics visible faster. That meant taking event streams—clicks, payments, sensor readings—and turning them into dashboards, alerts, and aggregates that humans could react to.

The dominant architecture for this is well known: a streaming pipeline (Kafka + Flink) feeds an OLAP database (ClickHouse, Druid, Pinot). Queries return in milliseconds. Charts update continuously. It's mature, scalable, and works.

But now the consumers aren't humans. They're models. Agents. Decision loops that run hundreds or thousands of times per second, each expecting to act on a coherent, current view of the world.

This is where the standard architecture starts to show its limits.

What Streaming + OLAP Actually Solves

Streaming + OLAP is designed for:

• Continuous aggregation. Counts, sums, and averages updated as events arrive.
• Fast reads at query time. Columnar storage optimized for analytical scans.
• Append-heavy workloads. High write throughput for event ingestion.
• Human-speed queries. Sub-second response for dashboards and reports.

These are real capabilities. If your goal is monitoring, alerting, or visual analytics, this stack delivers. The gap appears when the workload shifts from observing reality to acting on it—from asking "What happened?" to deciding "What should we do?"

The Core Gap

Decision-time workloads have different requirements. Streaming + OLAP was built for continuous observation, not transactional action. Four properties expose the architectural mismatch.

Split State

Streaming systems maintain intermediate state in one place (Flink's RocksDB, Kafka's changelog topics). OLAP databases maintain query-ready state in another (columnar segments, tiered storage). These aren't the same state—they're copies that sync periodically.

This means any read from the OLAP layer is, by definition, behind the stream. How far behind depends on the flush interval, the indexing lag, and the replication delay. For monitoring, the gap is tolerable. For decisions, it's a source of error that can't be eliminated without rethinking the architecture.

Temporal Misalignment

Decision-time systems need to read context as of a specific moment. Not "the latest materialized aggregate," but "the state of these five entities at the instant this decision must be made." Point-in-time queries across multiple entities, with transactional consistency, are not what OLAP databases optimize for.

OLAP excels at scanning large volumes of data for analytical patterns. It doesn't guarantee that two concurrent queries will see the same snapshot. For a dashboard, that's fine. For two agents coordinating on the same transaction, it's a correctness bug.

Mutation Fragility

OLAP databases are append-optimized. They accept writes readily. They handle updates grudgingly—or not at all. Late-arriving corrections, schema migrations, retroactive fixes: these are operational events in decision-time systems, and they're awkward in append-only architectures.

Streaming systems have the inverse problem. They're built for flow, not for correction. Replaying a stream to fix a bug means reprocessing everything downstream. State management becomes a versioning problem that the primitives don't natively solve.

Serving Mismatch

Decision-time reads aren't analytical queries. They're point lookups: "Give me the context for this user, this session, this entity—right now." OLAP is optimized for scans across many rows. Key-value serving at high concurrency is a different access pattern with different performance characteristics.

Teams work around this by caching OLAP outputs in Redis or another serving layer. That adds another hop, another sync lag, and another place where freshness degrades.

The Tradeoff You're Actually Making

Streaming + OLAP gives you:

• High write throughput
• Fast analytical queries
• Continuous aggregation
• Low cost per byte stored

It assumes you're willing to accept:

• Split state between processing and serving
• Eventual consistency between stream and query layer
• Milliseconds-to-seconds of staleness on reads
• Append-only semantics with limited mutation support

For observation workloads, these tradeoffs are reasonable. For decision workloads—where correctness depends on consistency and freshness—they're constraints that shape (and limit) what you can build.

What the System Model Requires

A decision-time system needs to collapse the gap between "data is ingested" and "data is queryable for decisions." That means:

• Unified state. One source of truth, not two copies that sync.
• Transactional reads. Point-in-time snapshots that span entities.
• Native serving. Key-value access patterns without an external cache.
• Mutable when necessary. Corrections and updates without full replay.

This isn't a criticism of streaming + OLAP. It's a recognition that the requirements are different. Monitoring infrastructure and decision infrastructure solve adjacent problems with different constraints.

The Architectural Implications

If you're building decision-time systems on streaming + OLAP, you're working against the grain. You'll add caching layers to reduce staleness. You'll build coordination logic to approximate consistency. You'll accept that "good enough" freshness means "sometimes wrong."

The alternative is infrastructure designed for decisions from the start: a unified system where writes, computation, and serving happen inside the same transactional boundary. Where freshness isn't a sync interval—it's a guarantee.

This is what a Context Lake provides. Not because streaming + OLAP is bad, but because the decision-time workload has constraints that monitoring infrastructure was never designed to meet.

The question isn't whether your current stack works. It's whether it works for the workload you're building toward.