Real-Time Analytics
Event streams processed and served at seconds of freshness, powering customer-facing dashboards and APIs.
Last reviewed: Aug 2, 2026
Assumed context
Applications
Customer-facing dashboards and APIs — not analysts at a SQL prompt.
Seconds
Event-to-queryable p95 under ~5s.
Up to 100k events/s
Sustained thousands to hundreds of thousands per second; bursty is normal.
3–8, on-call
Every layer here is a 24/7 service, not a scheduled job.
Any cloud
Cloud-deployed; nothing here is provider-specific.
Self-managed OSS
OSS for the data path; managed offerings acceptable at the edges.
Optimizing for: Freshness over completeness — the stream is the source of truth for this workload.
Layers
Data flows left to rightChange data capture
OptionalRequired when operational database state — accounts, entitlements, inventory — must be joined with the event stream or served alongside it.
Streams row-level database changes into the pipeline so operational state and events can be joined downstream — instead of request-time lookups against the source database. Delivery follows the fill: Flink CDC reads sources directly into stream processing; connector-based fills land changes on the backbone as topics.
Flink CDC streams snapshots plus row-level changes straight into the stream-processing layer — the join need that makes this layer required is the same one that brings Flink in, so there is no separate connector system to run.
If change events must live on Kafka topics for consumers beyond this pipeline, or CDC is needed without adopting Flink — the Kafka-native connector standard.
If it already runs for batch ingestion elsewhere and minutes of freshness is acceptable for the joined state — not a seconds-latency path.