AWSのバッチ処理でループを閉じるにはどうすればよいですか？

Question

私は書き込みをサポートするエンドポイントを私のAPIに持っています。問題のリソースは協調的であるため、並行書き込み要求が同時に到着することが予想されるのは妥当です。

書き込みの回数が少ない場合は、単純なラムダでは比較的簡単です - 現在の状態を読み込み、新しい状態を計算し、比較してスワップし、スワップが成功するか、あきらめるまでスピンします。どちらの場合も、適切なhttp応答を計算して呼び出し側に返します。

APIが成功した場合、競合する書き込みの浪費は、十分に高価になります。

自然な応答は、バッチを消費する関数を使用して要求をキューにコピーするように見えます。各バッチ内で、要求を順番に処理し、新しい書き込みを格納し、要求に対する適切な応答を計算します。

計算されたレスポンスをhttpレスポンスにコピーするオプションと、トレードオフとは何か考慮する必要がありますか？

私の感覚は、（同期的に）メッセージをエンキューした後に、のブロック/ポーリングが必要で、最終的に要求に対する応答が入力されることです。

Answer 1

これは答えを数えるかどうか分かりませんが、自然な応答がコピー/キュー/ブロックすることには同意しません。ある種の悲観的な同時性制御を取引しているような気がします（そして、Redisを使ってロックを実装するだけのほうが簡単かもしれません - ラムダ自体に別の問題があるあなたはさらに難しいと説明します）。

ユーザーはおそらく、待ち時間が長いため、このようなAPIは望ましくありません。

私の意見では、いくつかの共有状態の共同編集用に設計されたAPIは、APIを成功させる上位構造を持っています。例として会話を考えると、チャットを個々のメッセージに分解しますメッセージは他のメッセージに返信されています。会話の同時変更はほとんどの場合付加されます（ユーザーが個々のメッセージを編集できるようにすることはできますが、それはリソース競合のポイントではありません）。会話内のメッセージ数を非同期的に数えるそれは最終的に一貫しているということです。

あなたのAPIのドメインを見ることで、変更をターゲットにしてサブエンティティを変更することで競合を減らすように変更を公開する方法があるかどうかを確認することができます（APIがこれを単一のリソース、ストレージエンジンには必要ありません）。

イベントソーシングのようなモデルでは、変更自体が文字通り追加され、スナップショットと最近の変更から状態が導き出されるという別のオプションがあります。