Architecture cellulaire AWS : Mise à l’échelle de systèmes basés sur les événements avec DynamoDB, SNS et SQS

Accueil › Actualités › Architecture cellulaire AWS : Mise à l’échelle de systèmes basés sur les événements avec DynamoDB, SNS et SQS

14 mai 2026

Architecture cellulaire AWS : Mise à l’échelle de systèmes basés sur les événements avec DynamoDB, SNS et SQS

À l’époque du cloud-native, faire évoluer une architecture conduit fréquemment à un système massif et hautement interconnecté, où une seule défaillance peut provoquer une indisponibilité globale. L’Architecture Cellulaire (Cellular Architecture) résout ce problème en décomposant le système en domaines indépendants et isolés de défaillance, appelés cellules.

Dans ce tutoriel, vous allez bâtir une architecture hautement résiliente et orientée événements en utilisant le motif cellulaire combiné à un flux asynchrone basé sur :

Au lieu d’opérer avec un seul plan de données monolithique, vous déployerez plusieurs copies identiques de l’infrastructure (cellules). Une couche de routage légère en périphérie examinera les requêtes entrantes et les dirigera vers la cellule appropriée en s’appuyant sur une clé de partition, comme l’identifiant du locataire.

Si un événement problématique (poison pill) ou une dégradation localisée affecte une cellule spécifique, l’impact restera confiné uniquement à cette cellule, garantissant une disponibilité maximale pour les autres locataires du système.

Cette approche crée une barrière d’isolement des pannes stricte pour les systèmes distribués critiques.

2. Pré-requis

Pour mettre en œuvre cette architecture, vous aurez besoin de :

3. Étapes

Étape 1 : Définir le module cellule du Data Plane

Ce qu’il faut faire

Créez un module réutilisable dans Terraform encapsulant l’intégralité du pipeline orienté événements :

Ce module représente une cellule isolée et autonome.

Pourquoi c’est important

Le fondement principal de l’architecture cellulaire est la répétabilité.

En transformant le plan de données en un module, chaque cellule devient une copie identique et déterministe de l’infrastructure.

Cela garantit que :

Exemple Terraform

variable « cell_id » {
 description = « Identifiant unique de la cellule »
 type = string
}
resource « aws_dynamodb_table » « cell_table » {
 name = « app-data-cell-${var.cell_id} »
 billing_mode = « PAY_PER_REQUEST »
 hash_key = « id »
 attribute {
 name = « id »
 type = « S »
 }
 stream_enabled = true
 stream_view_type = « NEW_AND_OLD_IMAGES »
}
resource « aws_sns_topic » « cell_topic » {
 name = « processing-topic-cell-${var.cell_id} »
}
resource « aws_sqs_queue » « cell_queue » {
 name = « processing-queue-cell-${var.cell_id} »
}

Étape 2 : Déployer des cellules indépendantes

Ce qu’il faut faire

Dans le Terraform principal, déployez plusieurs cellules indépendantes.

Pourquoi cela importe

Ici, vous créez les limites physiques d’isolement.

Exemple :

Exemple

module "cell_alpha" {
 source = "./modules/event_driven_cell"
 cell_id = "alpha"
}
module "cell_beta" {
 source = "./modules/event_driven_cell"
 cell_id = "beta"
}
module "cell_gamma" {
 source = "./modules/event_driven_cell"
 cell_id = "gamma"
}

Étape 3 : Création du Control Plane

Ce qu’il faut faire

Créez une table globale dans DynamoDB chargée de cartographier :

Pourquoi cela compte

La couche de routage doit découvrir dynamiquement vers quelle cellule envoyer chaque requête.

Cette cartographie ne peut pas être codée en dur.

Exemple

resource "aws_dynamodb_table" "tenant_routing_map" {
 name = "global-tenant-cell-mapping"
 billing_mode = "PAY_PER_REQUEST"
 hash_key = "tenant_id"
 attribute {
 name = "tenant_id"
 type = "S"
 }
}

Étape 4 : Mise en place du Cell Router

Ce qu’il faut faire

Créez :

Ce Lambda va :

  1. Extraire l’identifiant du locataire à partir de la requête

  2. Consulter la table globale de routage

  3. Découvrir la cellule correcte

  4. Insérer les données dans le DynamoDB de cette cellule

Pourquoi cela compte

Le routeur doit être extrêmement fin (thin router).

Il ne doit pas contenir de règles métiers.

Toute la logique doit rester au sein des cellules.

Après le routage initial, le pipeline asynchrone prend le relais :

DynamoDB Streams
→ Lambda producteur
→ SNS
→ SQS
→ Lambda consommateur

Exemple Terraform

resource "aws_lambda_function" "cell_router" {
 function_name = "global-edge-router"
 handler = "router.handler"
 runtime = "nodejs20.x"
}

Problèmes courants

Dépendances entre cellules

L’erreur la plus grave consiste à autoriser le partage des ressources entre cellules.

Exemple incorrect :

Cela rompt complètement l’isolement.

Chaque cellule doit posséder ses propres données.

Goulot d’étranglement dans le Control Plane

Si le routeur interroge DynamoDB à chaque requête :

Solution :

Poison Pills et défaillances asynchrones

Si une charge utile invalide casse le Lambda consommateur :

L’avantage de l’architecture cellulaire est que cela n’affecte qu’une seule cellule.

La solution adaptée consiste à utiliser :

5. Conclusion

En combinant l’architecture cellulaire avec des systèmes orientés événements, vous créez une plateforme extrêmement résiliente et avec un rayon d’action maîtrisé.

La séparation entre :

garantit que les défaillances restent mathématiquement contenues.

Avec des modules Terraform, vous pouvez :

À mesure que l’architecture évolue, vous pouvez intégrer :

Le résultat est une infrastructure prête pour des applications distribuées critiques en mission à grande échelle.

Fabien Delpont

Auteur

Fabien Delpont

Fabien Delpont, développeur et créateur du site Python Doctor.