Architecture
Diagramme d'architecture de calcul en périphérie serverless avec emplacements CloudFront ou Cloudflare, fonctions Lambda@Edge pour les tests A/B et la personnalisation géographique, regroupement de requêtes par origin shield et stratégies de réponse cache-first. Ce modèle visualise comment le calcul se déplace vers la périphérie du réseau pour des réponses à ultra-faible latence, avec des fonctions edge modifiant les requêtes et réponses avant qu'elles n'atteignent l'origine. Essentiel pour les applications critiques en performance servant un public mondial.
Code FlowZap complet
User { # End User
n1: circle label:"Browser Request"
n2: rectangle label:"DNS Resolution (Route 53)"
n3: rectangle label:"Receive Optimized Response"
n4: circle label:"Page Rendered"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Edge.n5.handle(top) [label="Nearest PoP"]
n3.handle(right) -> n4.handle(left)
}
Edge { # Edge Network (CloudFront/Cloudflare)
n5: rectangle label:"Edge Location PoP"
n6: diamond label:"Cache Hit?"
n7: rectangle label:"Return Cached Response"
n8: rectangle label:"Edge Function (Lambda@Edge)"
n9: rectangle label:"A/B Test Routing"
n10: rectangle label:"Geo-Based Personalization"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="HIT"]
n6.handle(bottom) -> n8.handle(top) [label="MISS"]
n7.handle(top) -> User.n3.handle(bottom) [label="Fast Response"]
n8.handle(right) -> n9.handle(left) [label="Modify Request"]
n9.handle(right) -> n10.handle(left) [label="Personalize"]
n10.handle(bottom) -> Origin.n11.handle(top) [label="Forward"]
}
Origin { # Origin Services
n11: rectangle label:"Origin Shield"
n12: rectangle label:"Application Load Balancer"
n13: rectangle label:"Serverless API"
n14: rectangle label:"Static Asset Store (S3)"
n15: rectangle label:"Generate Response"
n11.handle(right) -> n12.handle(left) [label="Collapse Requests"]
n12.handle(right) -> n13.handle(left) [label="Dynamic"]
n12.handle(bottom) -> n14.handle(top) [label="Static"]
n13.handle(right) -> n15.handle(left) [label="Compute"]
n14.handle(right) -> n15.handle(left) [label="Assets"]
n15.handle(top) -> Edge.n8.handle(bottom) [label="Cache + Return"]
n15.handle(top) -> User.n3.handle(bottom) [label="Response"]
}
Pourquoi ce workflow ?
Serving all requests from a single origin region adds 100-300ms of latency for global users. Edge computing moves computation to CDN points of presence worldwide, enabling sub-50ms responses for personalization, A/B testing, and authentication—without the complexity of multi-region deployments.
Comment ça fonctionne
- Step 1: DNS resolves the user to the nearest edge location (point of presence).
- Step 2: The edge checks its cache for a valid response.
- Step 3: On cache miss, Lambda@Edge functions execute request modifications like A/B test routing and geo-personalization.
- Step 4: Origin Shield collapses duplicate requests to reduce origin load.
- Step 5: The origin processes the request and returns a cacheable response.
- Step 6: The edge caches the response and returns it to the user with minimal latency.
Alternatives
Multi-region deployments provide full compute at the edge but are expensive and complex. Cloudflare Workers offer a simpler edge compute model. This template shows the CDN-based edge computing architecture with Lambda@Edge.
Key Facts
| Template Name | Architecture de calcul en périphérie 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.