リアルタイム処理は、データが発生してからできるだけ短い遅延で取り込み、集計や判定、配信まで行う処理方式です。数秒〜数分以内に結果が必要な業務で使われ、バッチ処理のように一定時間まとめて処理する前提とは設計が変わります。実務では「どれだけ早ければリアルタイムと呼ぶか」をSLAとして決めることが出発点になるでしょう。
構成は、イベントを受ける入口（APIやログ収集）と、メッセージ基盤（キューやストリーム）、集計・判定を行うストリーム処理、結果の出力先（DB、キャッシュ、通知）に分けて考えると整理しやすいです。時系列の集計はウィンドウ処理で行い、遅延到着データや順序入れ替わりをどう扱うかが品質を左右します。状態管理（state）を持つ処理は障害復旧が難しくなるため、チェックポイントや再処理設計まで含めて作る必要があります。
運用でつまずきやすいのは、重複配信や再実行で同じイベントが二重計上されることなので、冪等性と一意キー設計が欠かせません。低遅延を追いすぎるとコストが跳ねやすく、ピーク時のバックプレッシャーや遅延増加を監視で早く検知する運用が重要です。要件によってはマイクロバッチで十分な場合もあるため、判断に使う締め切り時刻から逆算して方式を選ぶのが現実的です。
