ラムダアーキテクチャの有用性と適用性の限界を示唆したブログ記事を書いたJay Kreps氏は，ラムダにはさまざまなアイデアが含まれているものの，未成熟なツールであるがゆえに，ビッグデータの未来であるというよりも，結局は一時的なソリューションに過ぎない，と主張している。その上で氏は，自身がLinkedInで，KafkaとSamzaを使ったシステムを構築した経験をベースとして，それと同等のパフォーマンス特性，それよりも優れた開発および運用特性を備えているという代替アーキテクチャを提案する。
ラムダアーキテクチャ(Lambda Architecture)とは，スケーラビリティと耐障害性の両方を達成するため，リアルタイム処理でバッチ処理をミックスした，大規模なストリーム処理向けのアプローチである。 そのパターンとしては，Apache Hadoop上のMapReduceと，Apache Stormを使用して実装するのが一般的だ。Twitterでの経験をベースとしてこれを実装したNathan Marz氏が，"How To Beat the CAP Theorem" というタイトルのブログ記事で紹介している。氏はラムダアーキテクチャに関するWebサイト運営に加えて，近日中に書籍を出版する予定である。
Kreps氏は，ラムダの持つ２つの重要な教義 - データ入力は不変である，生の入力データを再処理して出力を再計算することができる - については認めている。生の入力データを保持することで，当初は考慮していなかった方法でデータを処理したり，何らかの理由で不正データがストアされた場合の復旧メカニズムを提供したりすることが可能になるからだ。再処理が必要になるのは，新たな出力フィールドが必要な場合や，以前のバージョンの処理コードにバグがあって不正な出力が行われた場合などだ。
同時にKreps氏は，ラムダには独特の開発と運用の難しさがあると考えている。ラムダでは，すべてのアルゴリズムを，バッチシステム用に１回，リアルタイムシステムのために１回，合わせて2回実施しなければならない。そしてクエリは，２つのシステムの結果をまとめ上げる必要がある。複雑なアルゴリズムを１度でも実装することの大変さを考えれば，それを２回行って，そこから不可避に生じる障害をデバッグするというのが，大変な作業なのは明白だ。その上，２つの分散マルチノードサービスを操作するのは，ひとつを操作するよりも複雑なことは間違いない。
Kreps氏はハイレベルなガイダンスとして，次のような要約をする。
最近では，レイテンシが重要でないのならばMapReduceのようなバッチ処理フレームワークを使用し，重要ならばストリーム処理フレームワークを使用するようにアドバイスしています。ただし，どうしても必要な場合を除いて，両方を同時に実行しようとしてはいけません。
ならばなぜ，ラムダアーキテクチャがこれ程もてはやされているのでしょう？私はその理由を，人々がますます複雑で，低レイテンシな処理システムを構築しようとしている点にある，と思っています。過去のデータを処理することが可能でスケーラブルな反面，レイテンシの高いバッチシステムや，レイテンシは低いが結果の再処理を行うことのできないストリーム処理では，彼らの問題を解決することはできません。これら２つをダクトテープで継ぎ合わせることで，実用的なソリューションを本当に構築することが可能なのです。
低レイテンシと大規模な履歴データセットの両方を必要とするユースケースに対して，Kreps氏は，リアルタイム処理システムで十分だと示唆している。再処理が必要な場合は，並列性を拡大して，履歴をすぐに再生すればソリューションになる。LinkedInでは現在，KafkaとSamzaを使ってこのソリューションを実装し，使用している。 同じしょうなアプローチがStormや，あるいは他のストリーム処理システムで動作しないはずはない，というのが氏の考えだ。単一のシステムはデバッグや開発が著しく容易な上に，これらの二つのアーキテクチャの実行時の効率はほとんど同じだ，と氏は考えている。
Kreps氏の記事に対するコミュニティの反応は総じて肯定的で，何人かは自身の経験と一致していることを認めている。@jcsalteregoのコメント，"非常によく書かれています。ありがとう。linkedInに比べれば規模はずっと小さいですが，私がこれまで見てきたものと共通する部分があります"。また@jijoejvは，"素晴らしい記事ですね。私たちは @Nextag で，"Kappa"アーキテクチャを１年半，Strom+Kafka(履歴90日)で使用していますが，バグ修正がとても簡単です。" Nathan Marz氏からの返答はまだ見られない。