Streaming gives fast answers, but live results can change. Late events, retries, and bugs can all affect the numbers. Batch processing is slower, but it can rebuild the result from more complete data.

Many systems need both: fresh numbers now and corrected numbers later.

Lambda Architecture does this with two paths over the same data. The speed layer gives quick results, the batch layer rebuilds trusted results, and the serving layer combines the two.

The downside is complexity. Teams often have to maintain the same business logic in two systems and keep both outputs consistent. Modern streaming engines, replayable logs, and lakehouse table formats have made classic Lambda less common, but the trade-off still matters.

This chapter explains what problem Lambda solves, how the batch, speed, and serving layers work together, why duplicate logic is risky, and when Lambda is still worth using.