# Lambda architecture vs Kappa architecture > Lambda architecture maintains separate batch and streaming paths, while Kappa uses one stream-processing path for both live events and historical replay. Choose Lambda when historical recomputation benefits from a separate batch engine; choose Kappa when the same streaming logic can handle both workloads and retained history supports rebuilding state. Source: https://sysround.com/compare/lambda-vs-kappa-architecture Updated: 2026-11-05 ## Side by side | | Lambda architecture | Kappa architecture | |---|---|---| | Processing paths | Separate batch and speed layers | One stream-processing path | | Historical recomputation | Batch jobs rebuild historical views | Replay events through streaming logic | | Serving results | Combine batch views with recent updates | Read stream-maintained materialized views | | Logic maintenance | Keep batch and streaming semantics aligned | Reuse logic across live processing and replay | | Late events | Batch recomputation can incorporate corrections | Windows, corrections, or targeted replay | | Recovery requirements | Raw history plus batch rebuild capacity | Replayable history, state recovery, spare capacity | | Main operational risk | Divergent results and incorrect view merging | Replay contention and slow catch-up | | Best fit | Distinct historical and low-latency workloads | Replayable, event-driven computations | ## The differences that matter Lambda separates historical computation from low-latency updates. A batch layer produces views over a durable raw dataset, while a speed layer covers events not yet represented there. Serving must combine them without gaps or double counting, often using a published batch version and explicit input boundaries. Kappa treats historical data as another input to the streaming computation. After a logic change, a new processor version can replay retained events into a separate view, catch up with live traffic, and replace the old view. One processing model reduces duplicated logic, but replay isolation and cutover still require engineering. Neither architecture guarantees correct counts by itself. Both need duplicate handling, defined event-time semantics, and a policy for late arrivals. Lambda's batch path is not inherently exact, and Kappa's streaming path is not inherently approximate; correctness depends on the computation and its inputs. The main cost difference appears during rebuilding. Lambda can use a batch engine suited to large scans and joins. Kappa needs sufficient replay throughput and recoverable history, whether in a log or an archive that can feed the same processor. If rebuilding shares resources with live processing, it can increase lag and threaten freshness. ## Choose Lambda architecture when - You need fresh provisional results alongside periodically recomputed historical results, and can define how the two are reconciled. - Historical jobs require large scans or joins that are substantially easier to express and operate in a separate batch engine. - You already have a reliable raw-data archive and batch platform, and adding a speed layer has a clear product benefit. - You accept maintaining two processing implementations in exchange for tuning historical and live workloads independently. ## Choose Kappa architecture when - Your calculations can use the same event-processing logic for live traffic and historical replay. - You retain enough source history to rebuild required views and can demonstrate that replay meets the recovery deadline. - Avoiding semantic drift between separate batch and streaming implementations is a priority. - You can isolate replay resources, build versioned output views, and switch readers safely after validation. ## Worked example: Rebuilding an ad-click aggregation view Suppose an ad-click system receives 100,000 events per second and needs counts within five seconds. A deduplication bug requires rebuilding one day of aggregates, or 8.64 billion events. With Kappa, a replacement processor writes to a new view while the old view keeps serving. If shared processing capacity is 600,000 events per second, live arrivals leave at most 500,000 events per second for catching up, giving an ideal minimum of 4.8 hours. State access and output writes can make it longer. Lambda could recompute that day with its batch engine instead, but must publish corrected results without overlapping the speed layer. Choose based on the rebuild deadline and available capacity. ## In the interview - Start with freshness and correction requirements: how quickly must a result appear, when may it change, and when is it considered final? Those answers matter more than naming an architecture. - For Lambda, draw the batch boundary and explain how serving excludes overlapping speed-layer contributions. Expect questions about late events, publishing a new batch view, and readers observing mixed versions. - For Kappa, estimate retained data volume and replay time. Explain whether replay has dedicated capacity or competes with live traffic, then describe how the rebuilt view catches up before cutover. - For either choice, explain deduplication, event-time windows, schema changes, and output writes during retries. Interviewers may ask whether an old event can still be interpreted correctly by the new processor. - Distinguish checkpoint recovery from full recomputation. Restoring a compatible checkpoint can recover a failed job quickly, but a logic change may require rebuilding state from source history. ## Common mistakes - Saying Lambda is accurate and Kappa is only approximate. Either can produce exact or approximate results, depending on its algorithms and correctness guarantees. - Calling every system with a stream processor Kappa without explaining how historical replay and state rebuilding work. - Assuming a replayable log retains history forever, or treating a checkpoint as a substitute for source data when recomputing changed logic. - Ignoring the hard serving step: avoiding overlap between Lambda views or preventing partial Kappa rebuilds from becoming visible. ## Interview questions where it comes up - [Design an ad click aggregator](https://sysround.com/questions/design-ad-click-aggregator): The choice determines how fresh click counts are reconciled with corrected historical aggregates and final billing totals. - [Design Google Analytics](https://sysround.com/questions/design-google-analytics): Live dashboards and historical session corrections require an explicit strategy for late events, deduplication, and recomputation. - [Design a metrics monitoring system like Datadog](https://sysround.com/questions/design-metrics-monitoring-system): Streaming rollups and historical rebuilds must preserve aggregation semantics without disrupting fresh metrics and alerts. - [Design a top K trending system](https://sysround.com/questions/design-top-k): Maintaining live rankings while replaying corrected events exposes window expiration, deduplication, and view-cutover trade-offs. - [Design an A/B testing platform](https://sysround.com/questions/design-ab-testing-platform): Fresh experiment dashboards and corrected exposure-to-outcome attribution can justify either separate historical computation or replay through shared logic. ## FAQ ### What is the main difference between Lambda and Kappa architecture? Lambda uses separate batch and streaming paths, then combines their results for serving. Kappa uses a single stream-processing model and handles historical recomputation by replaying events through it. ### Does Kappa architecture eliminate batch processing? It eliminates the separate batch computation path for the views built with that architecture. It does not mean every task runs continuously, or that the system cannot use object storage, bounded replays, or unrelated batch jobs. ### Is Kappa architecture always better than Lambda? No. Kappa reduces duplicated processing logic, but large replays can be slow or compete with live traffic. Lambda can be a better fit when historical computation needs a different execution engine, provided the team can manage two paths and reconcile their outputs correctly. ## Related concepts - [Stream processing](https://sysround.com/concepts/stream-processing) - [Windowing and watermarks](https://sysround.com/concepts/windowing) - [Materialized views](https://sysround.com/concepts/materialized-views) - [Data lakes and warehouses](https://sysround.com/concepts/data-lake) - [Idempotency and idempotency keys](https://sysround.com/concepts/idempotency) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.