“Architectural Foundations & Infrastructure - Part 2” — Data Engineering Central
Why this is in the vault
Lambda vs Kappa is foundational vocabulary for any data platform conversation. Ray Data Co will encounter these terms in consulting engagements, newsletter content, and client architecture reviews. This piece is a pragmatic, opinionated take rather than a textbook definition — useful for calibrating how practitioners actually think about the choice. Filed as reference, not as a strong novel insight.
⚠️ Sponsorship
Delta Lake sponsors this newsletter. The author discloses sponsorship inline and states personal use of Delta Lake. The article itself does not push Delta Lake or any specific tool — the argument is architecture-first, tool-agnostic. No meaningful bias detected in the Lambda/Kappa discussion. Treat the broader newsletter with awareness that lakehouse-ecosystem tools get favorable framing.
Core argument
Most real-world data platforms end up Lambda (separate batch and streaming pipelines), not Kappa (everything unified as streams). The author argues that pure Kappa is aspirational but rarely practical because even streaming-heavy orgs still run batch aggregation for dashboards and analytics. Two decision drivers should guide the choice: (1) data velocity and unit size, and (2) business requirements for freshness. The author warns against letting vendor marketing or personal preference drive the decision — “let the data itself tell you how it wants to be handled.”
Key positions:
- Most data needs are batch. Only some sources are naturally streaming. Forcing batch data through streaming tools adds unnecessary complexity.
- Kappa is a gold star on paper. In practice, even Kappa-leaning platforms usually have batch jobs running alongside, making them effectively Lambda.
- Let requirements drive architecture, not the reverse. Pre-picking streaming because it sounds modern, then forcing data into it, is a common anti-pattern.
- New frameworks are blurring the line. The author acknowledges that newer tools reduce the maintenance burden of streaming, making the batch/streaming boundary less painful than it used to be.
Mapping against Ray Data Co
For consulting contexts (phData and beyond), this reinforces a defensible default: recommend Lambda unless the client’s data velocity and business SLAs clearly demand streaming. The “let the data tell you” heuristic is a good qualifying question for early discovery calls — ask about data unit size and update frequency before proposing architecture.
For the data marketplace project, the platform will likely be Lambda: batch ingestion of datasets with potential streaming for real-time pricing or usage signals. No need to over-engineer a Kappa approach.
For Sanity Check newsletter content, Lambda vs Kappa is well-trodden ground but the “vendor marketing drives bad architecture choices” angle could pair with a broader piece on complexity creep in data stacks.
Related
- 06-reference/2026-01-05-seattle-data-guy-data-pipeline-patterns — SDG’s five pipeline pattern taxonomy; complementary vocabulary layer (what kinds of pipelines) vs this piece (how to arrange them architecturally)
- 06-reference/2026-04-04-dedp-design-patterns-intro — DEDP’s higher-level design pattern framework; Lambda/Kappa sits within the “data flow” strategic concern
- 06-reference/2026-04-04-dedp-challenges-de — DEDP on velocity as a core storage challenge; same decision driver this article highlights
- 06-reference/2026-04-04-dedp-semantic-layer-bi-olap-virtualization — Modern OLAP engines blur batch/streaming at query time, relevant to the “brave new world” section here
- 06-reference/2026-04-03-data-maturity-processes-tools — “Decisions not tools” framing aligns directly with this article’s anti-vendor-marketing stance
- [07-archive/readwise-thin/The Emerging Architectures for Modern Data Infrastructure](/vault/07-archive/readwise-thin/The Emerging Architectures for Modern Data Infrastructure/) — a16z reference architecture; warehouse vs lake convergence is the infrastructure backdrop for Lambda/Kappa choices
- [07-archive/readwise-thin/A Data Pipeline Is a Materialized View](/vault/07-archive/readwise-thin/A Data Pipeline Is a Materialized View/) — Conceptual framing of pipelines as derived views; update trigger and granularity map to the batch vs streaming decision