Microservices Event-Driven Communication with Streaming Databases
Lambda architecture runs parallel batch and streaming pipelines, merging results. Kappa architecture uses streaming only, replaying the stream for reprocessing. In 2026, neither pure Lambda nor Kappa is optimal — the modern approach is a streaming database (RisingWave) for real-time views plus an Iceberg lakehouse for historical analytics.
Architecture Comparison
| Architecture | Components | Complexity | Freshness |
| Lambda | Batch layer + stream layer + merge | High (two codepaths) | Real-time + batch |
| Kappa | Stream layer only | Medium (single codepath) | Real-time |
| Modern (Streaming + Lakehouse) | RisingWave + Iceberg | Low (SQL only) | Real-time + historical |
The Modern Approach
Sources → RisingWave → Materialized Views (real-time, sub-second)
→ Iceberg Sink (historical, query with Trino/DuckDB)
One pipeline, two outputs. No code duplication. No merge complexity.
Frequently Asked Questions
Is Lambda architecture dead?
Mostly, yes. The complexity of maintaining two codepaths (batch + stream) rarely justifies the benefit. Streaming databases + lakehouses achieve the same result with less complexity.
When is Kappa architecture appropriate?
When all data comes from a replayable event log (Kafka) and historical reprocessing means replaying the entire stream. For very large datasets, this replay can be expensive — making the lakehouse approach more practical.
