Une plateforme de trading sensible à la latence utilise Amazon DynamoDB (en mode à la demande). L'architecte de solutions doit améliorer les performances et assurer une haute disponibilité tout en atteignant une latence minimale. Quelle option répond à ces exigences ?

La bonne réponse est de créer un cluster DAX à trois nœuds et de configurer l'application pour lire via DAX tout en écrivant directement dans la table DynamoDB. DAX est un cache en mémoire qui réduit la latence des lectures de microsecondes, ce qui est crucial pour une plateforme de trading sensible à la latence. Un cluster à trois nœuds assure une haute disponibilité et une tolérance aux pannes. Les lectures sont acheminées via DAX pour bénéficier du cache, tandis que les écritures doivent contourner DAX et aller directement à DynamoDB pour garantir la cohérence immédiate des données. Les autres options sont incorrectes car : Un cluster à deux nœuds n'offre pas la même résilience qu'un cluster à trois nœuds. Écrire via DAX n'est pas recommandé car DAX est optimisé pour les lectures et n'offre pas les mêmes garanties de cohérence pour les écritures que DynamoDB directement. Lire directement depuis DynamoDB annulerait l'avantage de latence de DAX. Un cluster à nœud unique est un point de défaillance unique et ne garantit pas la haute disponibilité.