あるフィンテック企業が、DynamoDBで決済レコードを管理している。複数のマイクロサービスが同時に同じ決済レコードを更新しようとするケースがあり、楽観的ロック（Optimistic Locking）を実装して競合を検知したい。コードの変更を最小限に抑えてAWS SDKの機能を活用する最も適切な実装方法はどれか。
- A. DynamoDB DAXを導入してキャッシュ層を追加し、キャッシュコヒーレンシにより競合を防止する
- B. DynamoDB TransactWriteItemsを使い、すべての更新をトランザクションにまとめて競合を防止する
- C. 強整合性読み取り（ConsistentRead: true）でレコードを取得し、更新前に別のGetItemで再確認してから更新する
- D. AWS SDK（aws-dynamodb-enhanced-client等）のバージョン属性（@DynamoDbVersionAttribute）を使い、読み取り時のバージョン番号を更新時のConditionExpressionで検証する。不一致時はVersionMismatch例外をキャッチしてリトライする
解答と解説を見る
正解: D
楽観的ロックはAWS SDK Enhanced ClientでDynamoDbVersionAttributeアノテーションを使うか、手動でversionフィールドをConditionExpression（attribute_exists(version) AND version = :expectedVersion）で検証する方式で実現できる。読み取り時のバージョン番号を保持し、更新時にバージョンが一致する場合のみ書き込みを許可（一致すれば+1インクリメント）する。競合発生時はConditionalCheckFailedExceptionをキャッチしてリトライできる。AのDAXはキャッシュコヒーレンシを保証する仕組みがなく、並行書き込みの競合はDynamoDBレイヤーで発生するためDAX導入では解決しない。BのTransactWriteItemsは原子性のある複数アイテム更新には有効だが、楽観的ロックとは異なる概念で、単一アイテムの競合検知には過剰であり、トランザクションコストが高い。Cの強整合性読み取り+再確認は読み取りと書き込みの間に別のプロセスが更新できる時間窓が残り（ABA問題）、真の競合検知にはならない。