Architecture
Diagramme d'architecture de pipeline de données serverless avec ingestion Kinesis, fonctions de transformation Lambda, zones de stockage S3 data lake (brute et curatée), enregistrement au catalogue Glue et moteur de requêtes Athena alimentant des tableaux de bord QuickSight et des modèles ML SageMaker. Ce modèle représente un pipeline ETL serverless complet de l'ingestion à la transformation, au catalogage et à l'analyse sans gérer d'infrastructure. Idéal pour les équipes data construisant des plateformes analytiques économiques.
Code FlowZap complet
Ingestion { # Data Ingestion
n1: rectangle label:"Kinesis Data Stream"
n2: rectangle label:"API Gateway Endpoint"
n3: rectangle label:"IoT Core MQTT"
n4: rectangle label:"Kinesis Firehose"
n1.handle(right) -> n4.handle(left) [label="Stream"]
n2.handle(right) -> n4.handle(left) [label="Batch"]
n3.handle(right) -> n4.handle(left) [label="Device Data"]
n4.handle(bottom) -> Transform.n5.handle(top) [label="Buffer + Deliver"]
}
Transform { # Serverless Transform
n5: rectangle label:"Lambda Transform Function"
n6: rectangle label:"Validate Schema"
n7: diamond label:"Valid Record?"
n8: rectangle label:"Enrich with Reference Data"
n9: rectangle label:"Route to Error Bucket"
n10: rectangle label:"Partition by Date"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left)
n7.handle(right) -> n8.handle(left) [label="Valid"]
n7.handle(bottom) -> n9.handle(top) [label="Invalid"]
n8.handle(right) -> n10.handle(left) [label="Enriched"]
n10.handle(bottom) -> Storage.n11.handle(top) [label="Partitioned"]
}
Storage { # Data Lake Storage
n11: rectangle label:"S3 Raw Zone"
n12: rectangle label:"S3 Curated Zone"
n13: rectangle label:"Glue Catalog"
n14: rectangle label:"Athena Query Engine"
n11.handle(right) -> n12.handle(left) [label="Glue ETL Job"]
n12.handle(right) -> n13.handle(left) [label="Register Schema"]
n13.handle(right) -> n14.handle(left) [label="Queryable"]
}
Analytics { # Analytics Layer
n15: rectangle label:"QuickSight Dashboard"
n16: rectangle label:"SageMaker ML Model"
n17: rectangle label:"Redshift Data Warehouse"
n14.handle(bottom) -> Analytics.n15.handle(top) [label="Visualize"]
n14.handle(bottom) -> Analytics.n16.handle(top) [label="Train Model"]
n14.handle(bottom) -> Analytics.n17.handle(top) [label="COPY INTO"]
}
Pourquoi ce workflow ?
Traditional ETL pipelines require provisioning Spark clusters, managing job schedulers, and paying for always-on infrastructure. A serverless data pipeline uses managed services for every stage—ingestion, transformation, cataloging, and querying—eliminating infrastructure management while maintaining enterprise-grade data processing capabilities.
Comment ça fonctionne
- Step 1: Data streams from Kinesis, API Gateway, and IoT Core are buffered by Kinesis Firehose.
- Step 2: Lambda transform functions validate schemas, enrich records, and filter invalid data.
- Step 3: Transformed data lands in S3 raw zone, then is processed by Glue ETL into the curated zone.
- Step 4: The Glue Data Catalog registers schemas for all datasets.
- Step 5: Athena provides serverless SQL queries over the cataloged data.
- Step 6: QuickSight dashboards and SageMaker models consume the curated data for analytics and ML.
Alternatives
Self-managed Spark/Hadoop clusters offer more control but require significant DevOps investment. Snowflake or Databricks provide managed alternatives with different pricing models. This template shows the AWS-native serverless data pipeline.
Key Facts
| Template Name | Architecture de pipeline de données serverless |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.
Architecture
Diagramme d'architecture de migration Strangler Fig montrant le remplacement incrémental d'un monolithe legacy par de nouveaux microservices, utilisant une couche de routage pour répartir le trafic entre l'ancien et le nouveau système. Ce modèle représente la stratégie de migration éprouvée où les nouvelles fonctionnalités sont construites en microservices tandis que les endpoints legacy sont progressivement retirés. Essentiel pour les équipes modernisant des systèmes legacy sans réécriture risquée en big-bang.
Architecture
Diagramme d'architecture de découverte de services avec registre Consul ou Eureka, équilibrage de charge côté client, heartbeats de vérification de santé, et enregistrement/désenregistrement automatique des instances. Ce modèle visualise comment les microservices se localisent dynamiquement sans endpoints codés en dur, permettant une mise à l'échelle élastique et une infrastructure auto-réparatrice. Clé pour les équipes plateforme construisant une communication inter-services résiliente.