Amazon DynamoDB expliqué : concevoir des systèmes scalables

Ce qu’est DynamoDB et pourquoi les équipes l’utilisent

Amazon DynamoDB est un service de base de données NoSQL entièrement géré par AWS, conçu pour des applications nécessitant des lectures et écritures à faible latence de façon constante, à pratiquement n’importe quelle échelle. « Entièrement géré » signifie qu’AWS prend en charge le travail d’infrastructure — approvisionnement matériel, réplication, patching et beaucoup de tâches opérationnelles — afin que les équipes puissent se concentrer sur la livraison de fonctionnalités plutôt que sur l’exploitation des serveurs de base de données.

Au cœur, DynamoDB stocke des données sous forme d’items (lignes) dans des tables, mais chaque item peut avoir des attributs flexibles. Le modèle de données se comprend mieux comme un mélange de :

• Clé-valeur : récupérez rapidement un item par sa clé primaire, comme chercher un enregistrement par ID.
• Document : stockez des attributs imbriqués (maps et listes), similaire à JSON, utile pour des champs liés sans schéma strict.

Les équipes choisissent DynamoDB quand elles veulent des performances prévisibles et des opérations simplifiées pour des charges de travail qui ne se prêtent pas bien aux jointures relationnelles. Il est couramment utilisé pour les microservices (chaque service possédant ses données), les applications serverless à trafic en rafales, et les systèmes pilotés par événements qui réagissent aux changements de données.

Ce billet passe en revue les briques de base (tables, clés et index), comment modéliser selon les patterns d’accès (y compris la conception table-unique), comment fonctionnent la montée en charge et les modes de capacité, et des patterns pratiques pour streamer les changements dans une architecture événementielle.

Concepts de base : tables, items et clés primaires

DynamoDB s’organise autour de quelques blocs simples, mais les détails comptent car ils déterminent comment vous modélisez les données et à quelle vitesse (et à quel coût) les requêtes seront servies.

Tables, items et attributs

Une table est le conteneur de haut niveau. Chaque enregistrement dans une table est un item (similaire à une ligne), et chaque item est un ensemble d’attributs (similaire à des colonnes).

Contrairement aux bases relationnelles, les items dans une même table n’ont pas besoin de partager les mêmes attributs. Un item peut avoir {status, total, customerId}, tandis qu’un autre inclut {status, shipmentTracking} — DynamoDB n’exige pas de schéma fixe.

Clés primaires : simple vs composite

Chaque item est identifié de façon unique par une clé primaire, et DynamoDB supporte deux types :

• Clé primaire simple (partition key uniquement) : un attribut identifie de façon unique chaque item.
• Clé primaire composite (partition key + sort key) : plusieurs items peuvent partager la même partition key, tandis que la sort key les distingue et définit l’ordre au sein de cette partition.

En pratique, les clés composites permettent des accès groupés comme « toutes les commandes d’un client, les plus récentes en premier ».

Query vs Scan (niveau élevé)

Un Query lit des items par clé primaire (ou par la clé d’un index). Il cible une partition key spécifique et peut filtrer par plages de sort key — c’est la voie efficace et recommandée.

Un Scan parcourt toute la table (ou l’index) puis filtre. C’est facile à démarrer, mais généralement plus lent et plus coûteux à grande échelle.

Limites à garder en tête

Quelques contraintes à connaître :

• Taille max d’un item : 400 KB.
• Types d’attributs : scalaires (string/number/binary/boolean/null), sets, lists et maps.
• Les attributs de clé doivent être scalaires (pas de lists/maps comme partition ou sort key).

Ces fondamentaux conditionnent les patterns d’accès, les choix d’indexation et les caractéristiques de performance.

Le modèle de données de DynamoDB : clé-valeur et document

DynamoDB est souvent décrit à la fois comme un magasin clé-valeur et comme une base de documents. C’est exact, mais il est utile de comprendre ce que chacun implique dans la conception quotidienne.

Accès clé-valeur vs items de type document

Au fond, vous récupérez les données par clé. Fournissez les valeurs de la clé primaire et DynamoDB retourne un item. Cette recherche par clé est ce qui fournit un stockage à latence prévisible pour de nombreuses charges.

En même temps, un item peut contenir des attributs imbriqués (maps et listes), ce qui le fait ressembler à une base de documents : vous pouvez stocker des payloads structurés sans définir un schéma rigide à l’avance.

Modéliser des structures hiérarchiques de type JSON dans des items

Les items se prêtent naturellement à des données JSON-like :

• Maps représentent des objets (ex. profile.name, profile.address).
• Lists représentent des tableaux (ex. actions récentes, tags).

C’est adapté quand une entité est généralement lue en entier — profil utilisateur, panier d’achat ou bundle de configuration.

Quand dé-normaliser (et pourquoi c’est courant)

DynamoDB ne supporte pas les jointures côté serveur. Si votre appli doit récupérer « une commande plus ses lignes plus le statut d’expédition » en un seul parcours, vous dé-normaliserez souvent : copier des attributs dans plusieurs items, ou intégrer de petites sous-structures directement dans un item.

Compromis vs normalisation relationnelle

La dé-normalisation augmente la complexité à l’écriture et peut créer un fan-out de mises à jour. Le gain est moins d’aller-retour et des lectures plus rapides — souvent critique pour des systèmes scalables.

Clé de partition et clé de tri : concevoir pour les patterns d’accès

Les requêtes DynamoDB les plus rapides s’expriment comme « donne-moi cette partition » (et éventuellement « dans cette partition, donne-moi cette plage »). Le choix des clés concerne donc surtout comment vous lisez les données, pas seulement comment vous les stockez.

Partition key : distribution et lectures prévisibles

La partition key détermine quelle partition physique stocke un item. DynamoDB hashe cette valeur pour répartir données et trafic. Si de nombreuses requêtes convergent vers un petit ensemble de valeurs de partition key, vous pouvez créer des partitions « chaudes » et atteindre des limites de débit même si la table est globalement peu utilisée.

Bonnes partition keys :

• Ont une haute cardinalité (beaucoup de valeurs distinctes)
• Correspondent à un pattern d’accès fréquent (pour que les lectures soient directes, non filtrées)
• Évitent des valeurs qui deviennent « populaires » (par ex. une constante comme "GLOBAL")

Sort key : requêtes par plage et entités groupées

Avec une sort key, les items partageant la même partition key sont stockés ensemble et ordonnés par la sort key. Cela permet efficacement :

• Requêtes par plage (BETWEEN, begins_with)
• Lectures ordonnées dans le temps (les plus récentes en premier avec scans inversés)
• Regroupement d’entités (plusieurs types d’items sous une même partition key)

Un pattern courant est de composer la sort key, par exemple TYPE#id ou TS#2025-12-22T10:00:00Z, pour supporter plusieurs formes de requêtes sans multiplier les tables.

Mapper des patterns d’accès courants sur les clés

• Get by ID : PK = USER#<id> (simple GetItem)
• Lister par utilisateur : PK = USER#<id>, SK begins_with ORDER# (ou SK = CREATED_AT#...)
• Séries temporelles : PK = DEVICE#<id>, SK = TS#<timestamp> avec BETWEEN pour des fenêtres temporelles

Comment le choix de la clé affecte performance et scalabilité

Si votre partition key s’aligne sur vos requêtes les plus volumineuses et distribue uniformément, vous obtenez des lectures/écritures à faible latence de façon constante. Sinon, vous compensez par des scans, des filtres ou des indexes supplémentaires — chacun ajoutant du coût et augmentant le risque de clés chaudes.

Index secondaires : GSI et LSI expliqués

Les index secondaires offrent des chemins de requête alternatifs au-delà de la clé primaire de la table. Plutôt que de remodeler votre table de base chaque fois qu’un nouveau pattern d’accès apparaît, vous pouvez ajouter un index qui re-clés les mêmes items pour une autre requête.

GSI vs LSI : quelle différence ?

Un Global Secondary Index (GSI) possède sa propre partition key (et une sort key optionnelle) qui peut être complètement différente de celle de la table. Il est « global » car il traverse toutes les partitions de la table et peut être ajouté ou supprimé à tout moment. Utilisez un GSI quand vous avez besoin d’un nouveau pattern d’accès qui ne rentre pas dans la clé originale — par exemple, interroger des commandes par customerId alors que la table est indexée par orderId.

Un Local Secondary Index (LSI) partage la même partition key que la table de base mais utilise une sort key différente. Les LSI doivent être définis à la création de la table. Ils sont utiles pour avoir plusieurs ordres de tri au sein du même groupe d’entités (même partition key), comme récupérer les commandes d’un client triées par createdAt vs status.

Projections : ce qui est copié dans l’index

La projection détermine quels attributs DynamoDB stocke dans l’index :

• KEYS_ONLY : stockage le moins cher, mais vous devrez souvent relire la table de base.
• INCLUDE : copier seulement les attributs que vous retournez couramment.
• ALL : le plus simple, mais peut gonfler le stockage et le coût d’écriture.

Amplification des écritures (la facture cachée)

Chaque écriture sur la table de base peut déclencher des écritures dans un ou plusieurs indexes. Plus de GSI et des projections larges augmentent le coût d’écriture et la consommation de capacité. Planifiez les indexes autour des patterns d’accès stables et minimisez les attributs projetés quand c’est possible.

Modes de capacité et comportement de montée en charge

La montée en charge DynamoDB commence par un choix : On-Demand ou Provisioned. Les deux peuvent atteindre un très haut débit, mais se comportent différemment face aux variations de trafic.

On-Demand vs Provisioned : comment choisir

On-Demand est la solution la plus simple : vous payez par requête et DynamoDB s’ajuste automatiquement à la charge variable. C’est adapté aux trafics imprévisibles, aux produits en phase early-stage et aux charges en rafales où vous ne voulez pas gérer des cibles de capacité.

Provisioned consiste à planifier la capacité : vous spécifiez un débit de lecture et d’écriture (ou vous l’auto-scalez) et obtenez des coûts plus prévisibles pour une utilisation stable. C’est souvent moins cher pour des charges connues et pour les équipes capables de prévoir la demande.

Capacité lecture/écriture en pratique

Le débit provisionné se mesure en :

• RCUs (Read Capacity Units) : environ une lecture fortement consistante par seconde jusqu’à 4 KB (ou deux lectures éventuellement consistantes).
• WCUs (Write Capacity Units) : environ une écriture par seconde jusqu’à 1 KB.

La taille de l’item et le pattern d’accès déterminent le coût réel : items plus grands, consistance forte et scans peuvent consommer rapidement la capacité.

Bases de l’auto-scaling (et limites)

L’auto-scaling ajuste les RCUs/WCUs provisionnés selon des cibles d’utilisation. Il aide pour la croissance graduelle et les cycles prévisibles, mais n’est pas instantané. Les pics soudains peuvent toujours provoquer du throttling si la capacité ne monte pas assez vite, et il ne corrige pas une partition chaude qui concentre le trafic.

DAX : cache pour les charges en lecture

DynamoDB Accelerator (DAX) est un cache en mémoire qui peut réduire la latence de lecture et décharger les lectures répétées (ex. pages produit populaires, sessions). Il est utile quand de nombreux clients demandent souvent les mêmes items ; il n’aide pas les patterns à forte écriture et ne remplace pas une bonne conception de clés.

Consistance, transactions et exactitude

DynamoDB vous permet d’arbitrer entre garanties de lecture, latence et coût, il est donc important d’être explicite sur ce que signifie « correct » pour chaque opération.

Lectures éventuellement consistantes vs fortement consistantes

Par défaut, GetItem et Query utilisent des lectures éventuellement consistantes : vous pouvez brièvement voir une valeur antérieure juste après une écriture. C’est souvent acceptable pour des flux, catalogues produits et autres vues majoritairement en lecture.

Avec des lectures fortement consistantes (option possible pour des lectures depuis la table de base dans une région), DynamoDB garantit que vous voyez la dernière écriture reconnue. La consistance forte coûte plus en capacité de lecture et peut augmenter la latence en queue, donc réservez-la aux lectures vraiment critiques.

Quand la consistance forte est importante

La consistance forte est utile pour des lectures qui conditionnent des actions irréversibles :

• Vérifier le stock disponible avant de confirmer une commande
• Lire un flag d’autorisation avant d’accorder l’accès
• Récupérer l’état courant d’un workflow avant d’exécuter l’étape suivante

Pour des compteurs, l’approche la plus sûre est généralement une mise à jour atomique (ex. UpdateItem avec ADD) plutôt que « lire fort puis écrire », pour éviter les pertes d’incréments.

Lectures/écritures transactionnelles

Les transactions DynamoDB (TransactWriteItems, TransactGetItems) fournissent des sémantiques ACID sur jusqu’à 25 items. Elles sont utiles lorsque vous devez mettre à jour plusieurs items ensemble — par exemple écrire une commande et réserver l’inventaire — ou faire respecter des invariants qui ne tolèrent pas d’états intermédiaires.

Idempotence pour des tentatives sûres

Les retries sont normales dans les systèmes distribués. Rendre les écritures idempotentes pour que les réessais n’induisent pas d’effets en double :

• Utiliser un token de requête client (clé d’idempotence) stocké avec le résultat
• Faire respecter l’unicité avec ConditionExpression (ex. “créer seulement si attribute_not_exists”)
• Préférer les mises à jour atomiques plutôt que les boucles lire-modifier-écrire

L’exactitude avec DynamoDB consiste surtout à choisir le bon niveau de consistance et à concevoir les opérations pour que les réessais ne corrompent pas les données.

Partitions, clés chaudes et pics de trafic

DynamoDB répartit les données d’une table sur plusieurs partitions physiques. Chaque partition a un débit limité pour les lectures/écritures, ainsi qu’une capacité de stockage. Votre partition key détermine où vit un item ; si trop de requêtes ciblent la même valeur de partition key (ou un petit ensemble), cette partition devient le goulot d’étranglement.

Pourquoi apparaissent les partitions chaudes

Les partitions chaudes proviennent souvent de choix de clés qui concentrent le trafic : une clé « globale » comme USER#1, TENANT#default, ou STATUS#OPEN, ou des patterns ordonnés dans le temps où tout le monde écrit sur « maintenant » sous une même partition.

Symptômes de clés chaudes et trafic inégal

Vous verrez typiquement :

• Throttling (ProvisionedThroughputExceededException) pour un sous-ensemble de clés
• Latences élevées et éruptives pour quelques patterns d’accès pendant que d’autres restent rapides
• Métriques CloudWatch montrant une capacité consommée inégale et des pics soudains

Techniques d’atténuation

Concevez pour la distribution d’abord, puis pour la commodité des requêtes :

• Conception de clé : assurer des partition keys à haute cardinalité (par ex. TENANT#<id> au lieu d’une constante partagée).
• Sharding d’écriture : ajouter un petit suffixe/prefixe aléatoire ou hashé tel que ORDER#<id>#<shard> pour répartir les écritures sur N shards, puis interroger across shards si nécessaire.
• Buckets temporels : regrouper par heure/jour (METRIC#2025-12-22T10) pour éviter que « toutes les écritures aillent dans l’item le plus récent ».

Gérer des charges en rafales

Pour des pics imprévisibles, la capacité on-demand peut absorber les rafales (dans les limites du service). En mode provisioned, utilisez l’auto-scaling et implémentez un backoff exponentiel avec jitter côté client sur les throttles pour éviter des réessais synchronisés qui amplifient le pic.

Patterns de modélisation pour systèmes scalables

La modélisation DynamoDB part des patterns d’accès, pas des diagrammes ER. Vous concevez les clés pour que les requêtes nécessaires deviennent des Query rapides, tandis que le reste est évité ou traité de façon asynchrone.

Conception table-unique (et pourquoi elle plaît)

La « conception table-unique » consiste à stocker plusieurs types d’entités (utilisateurs, commandes, messages) dans une seule table et à utiliser des conventions de clés cohérentes pour récupérer des données liées en un seul Query. Cela réduit les allers-retours inter-entités et maintient une latence prévisible.

Une approche commune est les clés composites :

• PK groupe une partition logique (ex. USER#123)
• SK ordonne les items dans ce groupe (ex. PROFILE, ORDER#2025-12-01, MSG#000123)

Cela permet de récupérer « tout pour un utilisateur » ou « seulement les commandes d’un utilisateur » en choisissant un préfixe de sort-key.

Relations : listes d’adjacence et many-to-many

Pour des relations en graphe, une adjacency list fonctionne bien : stocker les arêtes comme items.

• PK = USER#123, SK = FOLLOWS#USER#456

Pour supporter les recherches inverses ou un véritable many-to-many, ajoutez un item d’arête inversée ou projetez sur un GSI selon les chemins de lecture.

Séries temporelles : bucket + sort key + TTL

Pour les événements et métriques, évitez des partitions non bornées en bucketant :

• PK = DEVICE#9#2025-12-22 (device + jour)
• SK = TS#1734825600 (timestamp)

Utilisez TTL pour expirer automatiquement les anciens points, et conservez des agrégats (rollups horaires/journaliers) comme items séparés pour des tableaux de bord rapides.

Si vous voulez un rappel plus approfondi sur les conventions de clé, voir /blog/partition-key-and-sort-key-design.

Streams et architectures pilotées par événements

DynamoDB Streams est le mécanisme natif de capture des changements (CDC). Lorsqu’il est activé sur une table, chaque insert, update ou delete produit un enregistrement de stream que des consommateurs en aval peuvent traiter — sans interroger la table.

Fondamentaux de DynamoDB Streams

Un enregistrement de stream contient les clés et (optionnellement) l’ancienne et/ou la nouvelle image de l’item, selon le stream view type choisi (keys only, new image, old image, both). Les enregistrements sont regroupés en shards, que vous lisez séquentiellement.

Construire des workflows événementiels

Un montage courant est DynamoDB Streams → AWS Lambda, où chaque lot d’enregistrements déclenche une fonction. D’autres consommateurs sont possibles (consommateurs personnalisés, ou envoi vers systèmes d’analytics/logging).

Workflows typiques :

• Vues matérialisées : écrire une table de read-model dénormalisée quand la table source change.
• Invalidation de cache : expirer ou rafraîchir des items dans Redis/ElastiCache après des écritures.
• Journaux d’audit : ajouter des événements immuables dans une table d’audit ou un store externe.

Cela permet de garder la table primaire optimisée pour des lectures/écritures à faible latence tout en déléguant le travail dérivé aux consommateurs asynchrones.

Ordre, réessais et exactitude

Streams fournit un traitement ordonné par shard (qui corrèle typiquement avec la partition key), mais pas un ordre global sur toutes les clés. La livraison est au moins une fois, donc des doublons peuvent survenir.

Pour gérer cela de manière sûre :

• Rendre les handlers idempotents (ex. upsert par clé primaire, utiliser des écritures conditionnelles, ou stocker les IDs d’événements traités).
• S’attendre à des réessais et des échecs partiels de batches ; utiliser des DLQ/destinations on-failure si possible.
• Isoler les effets secondaires (emails, paiements) derrière de la déduplication ou des protections transactionnelles.

Conçus avec ces garanties en tête, les Streams transforment DynamoDB en une base solide pour des systèmes pilotés par événements.

Fiabilité, sauvegardes et observabilité

DynamoDB est conçu pour une haute disponibilité en répartissant les données sur plusieurs Zones de Disponibilité dans une région. Pour la plupart des équipes, les gains pratiques en fiabilité viennent d’une stratégie claire de sauvegarde, de la compréhension des options de réplication et de la surveillance des métriques pertinentes.

Sauvegardes : on-demand vs point-in-time recovery

Les backups on-demand sont des snapshots manuels (ou automatisés) que vous prenez lorsque vous voulez un point de restauration connu — avant une migration, après une release, ou avant un backfill important. Ils sont pratiques pour des « signets ».

Le Point-in-Time Recovery (PITR) capture continuellement les changements pour restaurer la table à n’importe quelle seconde dans la fenêtre de rétention. PITR est le filet de sécurité contre des suppressions accidentelles, de mauvais déploiements ou des écritures malformées qui passent les validations.

Réplication et options multi-région

Si vous avez besoin de résilience multi-région ou de lectures à faible latence proches des utilisateurs, les Global Tables répliquent les données entre régions sélectionnées. Elles simplifient la planification de bascule, mais introduisent des délais de réplication cross-region et des considérations de résolution de conflits — clarifiez donc les patterns d’écriture et la propriété des items.

Surveillance essentielle

Au minimum, alertez sur :

• Latence (p95/p99) des lectures et écritures
• Requêtes throttlées et erreurs système
• Capacité consommée (et marge par rapport au provisionné)

Ces signaux font souvent remonter des problèmes de partition chaude, une capacité insuffisante ou des patterns d’accès inattendus.

Playbooks d’incident

Pour du throttling, identifiez d’abord le pattern d’accès en cause, puis atténuez en passant temporairement à on-demand ou en augmentant la capacité provisionnée, et envisagez de sharder les clés chaudes.

Pour des pannes partielles ou des erreurs élevées, réduisez le rayon d’impact : désactivez le trafic non critique, réessayez avec backoff et jitter, et dégradez gracieusement (par ex. servir des lectures en cache) jusqu’à stabilisation de la table.

Sécurité et contrôle d’accès

La sécurité DynamoDB concerne surtout qui peut appeler quelles actions API, depuis où et sur quelles clés. Puisque les tables peuvent contenir plusieurs types d’entités (et parfois plusieurs tenants), le contrôle d’accès doit être conçu en parallèle du modèle de données.

Permissions IAM : principe du moindre privilège

Commencez par des politiques IAM basées sur l’identité qui limitent les actions (ex. dynamodb:GetItem, Query, PutItem) au strict nécessaire et scopez-les aux ARNs de tables spécifiques.

Pour un contrôle plus fin, utilisez dynamodb:LeadingKeys pour restreindre l’accès selon les valeurs de partition key — utile quand un service ou tenant ne doit lire/écrire que dans son propre keyspace.

Chiffrement : points à vérifier

DynamoDB chiffre les données au repos par défaut en utilisant des clés AWS-owned ou une KMS gérée par le client. Si vous avez des exigences de conformité, vérifiez :

• Que la table est configurée avec la KMS voulue
• Que le rôle appelant possède les permissions KMS requises (et rien de plus)

Pour le chiffrement en transit, assurez-vous que les clients utilisent HTTPS (les SDK AWS le font par défaut). Si vous terminez TLS dans un proxy, confirmez que le saut entre le proxy et DynamoDB reste chiffré.

Contrôles réseau : réduire les voies d’exfiltration

Utilisez un VPC Gateway Endpoint pour DynamoDB afin que le trafic reste sur le réseau AWS et que vous puissiez appliquer des politiques d’endpoint pour contraindre l’accès. Associez cela à des contrôles d’egress (NACLs, security groups et routage) pour éviter des chemins « tout peut atteindre l’internet public ».

Conception multi-tenant et patterns d’isolation

Pour des tables partagées, incluez un identifiant tenant dans la partition key (par ex. TENANT#<id>), puis faites respecter l’isolation avec des conditions IAM sur dynamodb:LeadingKeys.

Si vous avez besoin d’une isolation plus forte, envisagez des tables séparées par tenant ou par environnement, et réservez les designs de table partagée aux cas où la simplicité opérationnelle et l’efficacité des coûts l’emportent sur un rayon d’impact réduit.

Optimisation des coûts pour DynamoDB

DynamoDB est souvent « bon marché quand vous êtes précis, coûteux quand vous êtes vague ». Les coûts suivent surtout vos patterns d’accès, donc le meilleur travail d’optimisation commence par expliciter ces patterns.

Connaître les leviers de coûts

Votre facture est principalement impactée par :

• Lectures et écritures (RCUs/WCUs en provisioned, unités de requête en on-demand)
• Stockage (données de la table et taille des items)
• Indexes secondaires (chaque GSI a ses coûts d’écriture et de stockage)
• Streams (lectures sur les enregistrements de stream et consommateurs en aval)

Une surprise courante : chaque écriture sur la table est aussi une écriture sur chaque GSI affecté, donc « encore un index » peut multiplier le coût d’écriture.

Concevoir des clés pour éviter le gaspillage

Une bonne conception de clés réduit le besoin d’opérations coûteuses. Si vous vous retrouvez souvent à utiliser Scan, vous payez pour lire des données que vous jetez.

Préférez :

• Query par partition key (et éventuellement conditions sur la sort key)
• Des projections étroites dans vos GSIs (projetez seulement ce dont vous avez réellement besoin)

Si un pattern d’accès est rare, envisagez de le servir via une table séparée, un job ETL, ou un read-model mis en cache plutôt que d’ajouter un GSI permanent.

Contrôler le stockage avec TTL et lifecycle

Utilisez TTL pour supprimer automatiquement les items à vie courte (sessions, tokens temporaires, états intermédiaires). Cela réduit le stockage et peut garder les indexes plus petits dans le temps.

Pour des données append-only (événements, logs), combinez TTL avec des designs de sort-key qui permettent d’interroger « récent seulement », afin de ne pas toucher l’historique froid régulièrement.

Dimensionner la capacité et éviter les pics accidentels

En mode provisioned, fixez des baselines conservatrices et scalez avec l’auto-scaling basé sur des métriques réelles. En on-demand, surveillez les patterns inefficaces (items volumineux, clients bavards) qui font monter le volume de requêtes.

Considérez Scan comme dernier recours — quand vous devez réellement traiter toute la table, planifiez-le hors-pointe ou exécutez-le comme batch contrôlé avec pagination et backoff.

Quand choisir DynamoDB (et quand ne pas le choisir)

DynamoDB excelle quand votre application peut s’exprimer comme un ensemble de patterns d’accès bien définis et que vous avez besoin d’une latence faible et constante à grande échelle. Si vous pouvez décrire vos lectures et écritures à l’avance (par partition key, sort key et quelques indexes), c’est souvent l’un des moyens les plus simples d’exploiter un store hautement disponible.

Cas d’utilisation idéaux

DynamoDB est un bon choix lorsque vous avez :

• Des requêtes prévisibles (charger un profil utilisateur, lister les commandes d’un utilisateur par date, charger une session par ID)
• Un débit d’écriture élevé ou un trafic en rafales que vous ne voulez pas piloter manuellement
• Le besoin d’une scalabilité horizontale sans gérer des serveurs
• Des designs pilotés par événements utilisant Streams pour déclencher du travail en aval

Quand envisager d’autres alternatives

Cherchez ailleurs si vos besoins principaux incluent :

• Des jointures complexes entre nombreuses entités ou des traversées de relations fréquentes
• Des requêtes ad hoc et analytiques qui changent souvent (group-bys, filtres exploratoires)
• Recherche textuelle avancée et ranking de pertinence sans index externe

Approches hybrides qui fonctionnent bien

Beaucoup d’équipes gardent DynamoDB pour les lectures/écritures « chaudes » et ajoutent :

• S3 + Athena pour l’analytics et le reporting historique
• OpenSearch (ou équivalent) pour la recherche full-text et le faceting
• Une couche de cache quand certaines clés sont extrêmement sollicitées en lecture

Note prototypage : raccourcir le chemin du modèle à l’appli

Si vous validez des patterns d’accès et des conventions table-unique, la rapidité compte. Les équipes prototypent parfois le service et l’interface dans Koder.ai (plateforme vibe-coding qui construit web, backend et mobile depuis une conversation) puis itèrent sur la conception des clés DynamoDB à mesure que des chemins de requête réels émergent. Même si le backend final diffère, des prototypes bout-en-bout aident à révéler quelles requêtes doivent être des Query plutôt que des scans coûteux.

Checklist de décision rapide

Validez : (1) vos principales requêtes sont connues et basées sur des clés, (2) les besoins de consistance correspondent au modèle choisi, (3) la taille attendue des items et leur croissance sont comprises, et (4) le modèle de coût (on-demand vs provisioned + autoscaling) convient à votre budget.