Lambda's safety net was needed because early streaming was unreliable. The reasons have largely gone:
Correct streaming engines. Kafka 129 's transactions and Flink 129 's checkpointed state give exactly-once results within the pipeline (Transactions and Exactly-Once and ksqlDB and Apache Flink), so the batch layer no longer has to correct the stream.
Cheaper long retention. Tiered storage keeps old log segments in object storage instead of on broker disks; the Apache Kafka 3.9 release announcement (November 2024) declared it production-ready (Tuning and Tiered Storage).
Unified engines. Flink runs the same program over bounded and unbounded input, and Spark 129 Structured Streaming uses the DataFrame API of its batch jobs, so one code base can serve both modes even when two paths remain.
Streaming into tables. Open table formats such as Iceberg 129 and Delta accept continuous writes and support time travel, so a streamed table can be queried like a warehouse table (Streaming into the Lakehouse).
In practice, many modern platforms are neither pure Lambda nor pure Kappa. A common shape is the "streaming lakehouse": events flow through Kafka into lakehouse tables, a few latency-critical results are computed by stream jobs, and the bulk of modeling runs as scheduled SQL over the same tables. What has disappeared is the defining flaw of Lambda, the same business logic written twice. When you design a pipeline, keep each rule in one place, and choose batch or streaming execution per use case (Batch or Streaming?).