Amazon DynamoDB — La base NoSQL serverless à l'échelle d'Internet (Partie 1)

Amazon DynamoDB est la base de données NoSQL serverless d'AWS. Elle offre des performances en millisecondes à un chiffre, quelle que soit la taille de vos données ou la charge de requêtes. Pas de serveur à gérer, pas de réplication à configurer, pas de failover à planifier — AWS gère tout.

DynamoDB propulse certains des services les plus critiques d'Amazon : le panier d'achat d'Amazon.com, Alexa, Twitch, et des milliers de microservices internes. Mais cette puissance a un prix : la modélisation des données est radicalement différente du relationnel. Si vous abordez DynamoDB avec un mindset SQL, vous allez droit dans le mur.

Cette première partie pose les fondamentaux : le modèle de données, les modes de capacité et de cohérence, le changement de paradigme qu'impose la modélisation, les cas d'usage où DynamoDB excelle et ceux où il faut regarder ailleurs. La seconde partie passe à la pratique avec un système e-commerce complet.

Présentation du service

Qu'est-ce qu'Amazon DynamoDB ?

DynamoDB est une base de données key-value et document, entièrement managée, qui offre :

• Performance constante : latence 10ms en lecture/écriture, indépendamment du volume de données
• Scalabilité illimitée : de quelques requêtes/jour à des millions/seconde
• Haute disponibilité : réplication automatique sur 3 AZ, SLA 99,999% (tables Global)
• Serverless : pas de provisionnement, pas de maintenance, pas de patching
• Intégration native : Lambda, AppSync, API Gateway, Kinesis, S3, EventBridge

Architecture interne simplifiée

Client SDK
    ↓
DynamoDB Request Router (choisit la partition)
    ↓
Storage Nodes (B-tree sur SSD, 3 répliques)
    ↓
Write: Quorum (2/3 répliques confirment)
Read: Leader (strongly consistent) ou Any (eventually consistent)

Concepts fondamentaux

Modèles de capacité

RCU (Read Capacity Unit) = 1 lecture strongly consistent de 4 Ko/s WCU (Write Capacity Unit) = 1 écriture de 1 Ko/s

Modèles de cohérence

• Eventually Consistent Read (par défaut) : latence plus faible, 0,5 RCU par lecture 4 Ko. Les données peuvent être légèrement en retard (~1 seconde).
• Strongly Consistent Read : 1 RCU par lecture 4 Ko. Garantit la dernière version écrite.
• Transactional Read/Write : 2× le coût. ACID sur un ou plusieurs items.

La modélisation en DynamoDB — Penser différemment

Le paradigme shift

En SQL, vous modélisez vos données puis vous écrivez des requêtes. En DynamoDB, c'est l'inverse : vous identifiez vos access patterns d'abord, puis vous modélisez pour les servir efficacement.

SQL thinking:
  "J'ai des Users et des Orders, je les mets dans 2 tables et je JOIN"

DynamoDB thinking:
  "J'ai besoin de : 
    1. Récupérer un user par ID
    2. Lister les commandes d'un user triées par date
    3. Récupérer une commande avec ses items
    4. Lister les commandes par statut
   → Je modélise une seule table pour servir ces 4 patterns"

Single-Table Design

Le pattern le plus puissant (et le plus déroutant pour les développeurs SQL) : stocker plusieurs entités dans une seule table.

Pourquoi ?

• Une seule Query peut récupérer un user ET ses commandes (même partition)
• Pas de JOIN nécessaire — tout est pré-jointé par le design
• Transactions sur plusieurs entités dans la même table
• Un seul point d'administration, de monitoring et de backup

Structure type :

Access Patterns servis :

1. Get user profile : PK = USER#123, SK = PROFILE
2. List user orders : PK = USER#123, SK begins_with("ORDER#")
3. Get order with items : PK = ORDER#abc, SK begins_with("ITEM#")
4. Orders by status : GSI avec GSI1-PK = STATUS#shipped

Cas d'usage

1. Backends serverless (API + Lambda)

DynamoDB est le compagnon naturel de Lambda :

• Pas de connexion pool — chaque invocation Lambda fait des appels HTTP indépendants
• Scaling parallèle — DynamoDB scale indépendamment de Lambda
• On-Demand — pas de planification de capacité nécessaire
• Latence constante — pas de cold start de connexion DB

Architecture classique :

API Gateway → Lambda → DynamoDB
                     → S3 (fichiers)
                     → SQS (async)

2. Session stores et user profiles

DynamoDB excelle pour stocker des sessions utilisateur :

• TTL natif — les sessions expirent automatiquement (suppression gratuite)
• Latence sub-10ms — pas d'impact sur l'UX
• Scale infini — des millions de sessions simultanées
• Pas de cluster à gérer — contrairement à Redis/ElastiCache

PK: SESSION#<session-id>
TTL: unix timestamp (expiration)
Data: {userId, cart, preferences, lastAccess}

3. Gaming — Leaderboards et inventaires

DynamoDB est massivement utilisé dans le gaming :

• Leaderboards : Sort Key numérique pour le score, Query triée
• Inventaire joueur : PK = PLAYER#id, SK = ITEM#xxx
• Matchmaking : GSI sur le rang/skill level
• Achievements : PK = PLAYER#id, SK = ACHIEVEMENT#xxx

4. IoT — Ingestion de données capteurs

Pour l'Internet des objets, DynamoDB absorbe des millions d'écritures/seconde :

PK: DEVICE#sensor-001
SK: TIMESTAMP#2026-09-28T14:30:00Z
Data: {temperature: 23.5, humidity: 65, battery: 87}

• Write-optimized — burst capacity absorbe les pics
• TTL — supprimer les données anciennes automatiquement
• Streams → Lambda pour les alertes temps réel
• Export to S3 — pour l'analytics long terme (Athena)

5. E-commerce — Paniers et catalogues

Le panier d'Amazon.com lui-même tourne sur DynamoDB :

• Panier : PK = CART#userId, items en tant qu'attributs
• Catalogue : PK = PRODUCT#id avec GSI sur catégorie, prix
• Commandes : Single-table design avec user + orders + items
• Stock : Conditional writes pour décrémenter atomiquement

6. Microservices — Event sourcing et CQRS

DynamoDB + Streams permet un pattern event-sourcing natif :

Write (Command) → DynamoDB (event store)
    ↓ (Stream)
Lambda → Projet les vues matérialisées
    ↓
DynamoDB (read-optimized views) ← Read (Query)

7. Configuration et feature flags

Stocker la configuration applicative dans DynamoDB :

• Lecture sub-ms avec DAX (cache)
• Mise à jour en temps réel via Streams → push to clients
• Versioning — Sort Key = version number
• Multi-tenant — PK = TENANT#id, SK = CONFIG#key

Quand NE PAS utiliser Amazon DynamoDB

1. Requêtes ad-hoc et analytics

Le problème : DynamoDB ne supporte pas SQL. Vous ne pouvez pas faire de JOIN, GROUP BY, sous-requêtes, agrégations complexes ou requêtes exploratoires sur des colonnes non-indexées.

Symptômes : Votre équipe data veut explorer les données avec des requêtes comme "combien de commandes par pays ce mois-ci" et vous devez créer un GSI pour chaque nouvelle question.

Alternative :

• Exportez vers S3 + Athena pour l'analytics
• Utilisez RDS/Aurora pour les workloads relationnels
• Redshift pour le data warehousing

2. Données hautement relationnelles (many-to-many)

Le problème : Si votre modèle a des relations many-to-many complexes avec des traversées de graphe (amis d'amis, recommandations, dépendances), DynamoDB devient très difficile à modéliser.

Symptômes : Vous créez 10 GSI pour servir vos access patterns et chaque modification de schema casse des queries existantes.

Alternative :

• Amazon Neptune (base de données graphe)
• RDS PostgreSQL pour les relations complexes
• Amazon OpenSearch pour la recherche full-text avec facettes

3. Transactions complexes multi-tables

Le problème : DynamoDB supporte les transactions (TransactWriteItems, TransactGetItems) mais limitées à 100 items et 4 Mo par transaction. Pas de rollback implicite, pas de savepoints, pas de triggers SQL.

Symptômes : Votre logique métier nécessite des transactions sur 500+ items avec des conditions complexes et des contraintes d'intégrité référentielle.

Alternative : Aurora PostgreSQL/MySQL pour les workloads transactionnels lourds. Amazon QLDB si vous avez besoin d'un ledger immuable.

4. Full-text search

Le problème : DynamoDB ne supporte que le filtrage exact (=), les plages (between), et begins_with. Pas de recherche floue, pas de scoring de pertinence, pas de stemming.

Symptômes : Vous voulez chercher "aws lambda tutoriel" et trouver des articles contenant "AWS Lambda tutorial".

Alternative : Amazon OpenSearch Service pour la recherche full-text. Combinaison DynamoDB (stockage primaire) + OpenSearch (index de recherche) via DynamoDB Streams.

5. Données > 400 Ko par item

Le problème : Un item DynamoDB ne peut pas dépasser 400 Ko. Si vous stockez des documents, des images encodées en base64, ou des objets JSON volumineux, vous atteindrez cette limite.

Symptômes : Vous avez des items qui grossissent avec le temps (historique, logs, commentaires) et finissent par dépasser 400 Ko.

Alternative :

• S3 pour les fichiers volumineux (stockez juste le lien S3 dans DynamoDB)
• Amazon DocumentDB si vous avez besoin de documents JSON > 400 Ko
• Pattern : DynamoDB pour les métadonnées, S3 pour le contenu

6. Rapports et exports massifs

Le problème : Scanner une table DynamoDB entière est lent et coûteux. Un Scan consomme des RCU proportionnellement à la taille de la table, pas au nombre de résultats retournés.

Symptômes : Votre rapport mensuel Scan une table de 50 Go et prend 2 heures, consomme des milliers de RCU et impacte le trafic production.

Alternative :

• DynamoDB Export to S3 (natif, ne consomme pas de RCU) + Athena
• DynamoDB Streams → S3 → Redshift pour le warehousing
• Séparer les données OLTP (DynamoDB) des données OLAP (Redshift/Athena)

7. Schéma qui évolue fréquemment avec migrations

Le problème : DynamoDB est schema-less, ce qui semble flexible. Mais en pratique, changer un access pattern fondamental (modifier la PK ou SK) nécessite de recréer la table ou migrer tous les items — un processus complexe et risqué.

Symptômes : Vous réalisez après 6 mois que votre choix de Partition Key ne supporte pas un nouveau use case et vous devez migrer des millions d'items.

Alternative : PostgreSQL avec des migrations Flyway/Liquibase. Le schema évolutif est plus simple en relationnel (ALTER TABLE est atomique).

Ce qu'il faut retenir

DynamoDB n'est pas « une base de données SQL sans SQL ». C'est un moteur de stockage distribué qui échange la flexibilité des requêtes contre une latence et un scaling garantis. Cet échange est excellent quand vous connaissez vos access patterns, et catastrophique quand vous ne les connaissez pas.

Les trois questions à se poser avant de choisir DynamoDB :

1. Puis-je lister mes access patterns aujourd'hui ? Si la réponse est « on verra plus tard », prenez du relationnel.
2. Mes requêtes sont-elles connues et bornées ? Les requêtes ad-hoc, les agrégations et la recherche full-text appartiennent à d'autres services.
3. Ai-je besoin d'une latence constante à n'importe quelle échelle ? C'est là que DynamoDB n'a pas d'équivalent.

Dans la seconde partie, nous passons à la pratique : patterns de modélisation avancés (overloading GSI, sparse index, write sharding, adjacency list), puis un système e-commerce complet en single-table design avec TypeScript et Terraform, DynamoDB Streams et une checklist de production.