はじめに
髙橋愛理です！ 
AWSサーバーレス開発のチームリーダーやってます。
AWSを代表するNoSQL、DynamoDB。
現在行っている開発では、こいつを使ってサーバレス開発を行っています。
今回は、私が実際開発して感じた、DynamoDB Streamのメリット、デメリット、使用方法などをまとめてみました。
DynamoDB Streamとは
DynamoDBは、AWSを代表するNoSQLです。
DynamoDBには、DynamoDB Streamという機能があるのですが、これは、DynamoDBにデータの更新があった際、Lambda関数を起動して非同期で処理を行うことができるというものです。
DynamoDB Streamで起動したLambda関数では、INSERT（作成）、MODIFY（更新）、REMOVE（削除）のイベントと、新旧のデータを受け取ることができます。
メリット
私的に、DynamoDBを使用する一番のメリットって、コンポーネント間連携に使えることと、データ変更時に一律で行いたい処理を一か所にまとめることが出来ることかと思います。
デメリット
DynamoDB Streamを使うことのデメリットは、タイムラグが生じるので結果整合性的になることと、処理が失敗した際に整合性が失われることだと思います。
💭
よほど重たい処理でなければ、実際そこまでのタイムラグはないけどね
実際の使用例
実際私が開発で、採用している実装例を紹介したいと思います。
総数の集計処理
例えば、チャットアプリの「いいね」の総数のincrement、decrementなどです。
APIから「いいね」の作成削除を行い、DynamoDB Streamで総数のincrement、decrement処理を行うことで、
レコードの作成削除と、総数の処理を分離し、総数の処理を一か所にまとめることが出来ます。
💭
DynamoDBの苦手な集計処理をカバーしてくれるよ
機能間連携させる
いわゆるコンポーネント間連携です。
例えば、通知メッセージを格納するテーブルにDynamoDB Streamをアタッチし、
通知メッセージの作成があったら、通知送信処理を行うコンポーネント（SNS等）にメッセージを送信することで、通知メッセージ作成と通知送信の処理の、別々のコンポーネント間を連携させることができます。
💭
コンポーネントの疎結合化で変更に強いアーキテクチャになるね！
関連リソースの作成削除
関連する別テーブルのリソースの作成削除を行う場合です。
ユーザが削除された時、ユーザテーブルのDynamoDB Streamから、削除されたユーザの関連リソースの削除を行うことによって、
関連リソースの削除を待たず、ユーザ削除のレスポンスをクライアントへ返すことができます。
💭
処理が重たくなりそうならSQSも組み合わせるよ！
最後に
デメリットもありますが、うまく使えばそれ以上にメリットをもたらしてくれると思ってます。
あくまで私の考えや使い方ですが、参考にしていただけたら嬉しいです。