（アーキテクチャの？）拡張性については、QAタイムにお答えしたように、例外を作らずにRedshiftに寄せていくことがポイントと思います。

（取り込む各種データの？）整合性については、あるていど諦めている面はあります。基本的には集計して使うので、集計結果の大勢に影響するような大きな誤差でなければ許容するというスタンスです。

一方、もし売上の処理のように誤差が許容できない処理がある場合は、例えば元データを履歴で持って行の更新が起こらないようなデータ形式にするなどの工夫をすると思います。行の更新が起こらなければ「いつ取り込むか」ではなくて「どこまで取り込んだか」という問題になるので、話がシンプルになります。

詳細なご回答ありがとうございます。
他の勉強会でkoibumiみるまでコメントいただいていることに気付きませんでした。。
質問の意図はご回答いただいた通りでした。

データ生成元に制限を与えない一方で(Redshift以外の)例外を作らずにデータ基盤を提供するために、データ構造を吸収したり一貫性を検証したり、設計ポイントは色々ありそうだと感じました。

職場でもちょうどデータ基盤の構築&導入を始めているため、可能であれば自身もナレッジをアウトプットしていきます。