MartinFowlerによるLMAXアーキテクチャの説明から次のシナリオを検討してください。
説明のために、LMAX以外の簡単な例を使用します。クレジットカードでゼリービーンズを注文していると想像してみてください。<...>
LMAXアーキテクチャでは、この操作を2つに分割します。最初の操作では、注文情報を取得し、イベント（クレジットカードの検証が要求された）をクレジットカード会社に出力して終了します。次に、ビジネスロジックプロセッサは、入力イベントストリームでクレジットカードで検証されたイベントを受信するまで、他の顧客のイベントの処理を続行します。そのイベントを処理すると、その注文の確認タスクが実行されます。
したがって、支払い処理の結果を受け取るまで、注文はメモリに保持されます。
ここで、クレジットカードの処理ステップの代わりに、はるかに時間がかかるステップがあると仮定します。たとえば、在庫チェックを実行する必要があります。この場合、注文したジェリービーンズの特定のフレーバーがあることを誰かが物理的に確認する必要があります。これには1時間かかる場合があります。
この場合、多くの注文が在庫状況の更新イベントを待機している可能性があるため、メモリに保持されているデータの増加につながることはありませんか？
おそらくそのようなシナリオでは、メモリから注文を削除し、それを出力イベントの一部として含める必要があります。外部システム（在庫）は、注文の詳細を含む別の入力イベントを生成する責任があります。
このアプローチで私が目にする問題は、ビジネスロジックプロセッサの一部として在庫を含めることができないことです。
これにどのように対処するかについての考えは？