À la fin de ce tutoriel, vous saurez clarifier un brief system design (SLO, RPO/RTO, trafic), dessiner une architecture multi-AZ en ca-central-1, faire des estimations de capacité, anticiper les modes de panne, et produire un design doc lab (API paiements) prêt pour entretien DevOps / Platform — sans cluster coûteux.

Niveau : Intermédiaire · Temps estimé : 55–75 min · Versions cibles : concepts 2026 · AWS CLI v2 · ECS/Fargate ou EKS (option) · CloudWatch · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-system-design-devops · Série : WOW (49/50) · Mot-clé SEO : system design devops · Publish : HOLD

← Précédent : Entretien DevOps 2026 · → Suivant : Portfolio GitHub DevOps · Aussi : Platform Engineering · SRE error budgets

Prérequis

• Bases DevOps : HTTP, conteneurs, CI/CD — Docker · Kubernetes
• Notions AWS (VPC, IAM, ALB) — Démarrer avec AWS
• Profil AWS lab (lab) et budget d’alerte activé
• Un éditeur Markdown pour le design doc

Coût estimé : 0 € si vous restez sur le design + sts get-caller-identity. Si vous provisionnez un lab réel plus tard : détruysez tout ; pas de NAT Gateway / RDS / EKS « pour le fun ».

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity

Ce que nous allons construire

System design DevOps / Platform (WOW 49/50) — ca-central-1
  ├── Clarifier exigences (SLO, RPO/RTO, trafic, data)
  ├── Architecture de référence multi-AZ
  ├── Trade-offs (latence, coût, cohérence, ops)
  ├── Estimations back-of-envelope
  ├── Lab : design doc API paiements + checklist
  └── Quiz + FAQ + maillage WOW

(Schéma — alt : « System design DevOps : du brief SLO à une API paiements multi-AZ en ca-central-1 ».)

Étape 1 — System design : angle DevOps / Platform

En entretien software, on parle souvent d’algorithmes et de sharding. En DevOps / Platform, le jury attend surtout :

1. Exigences opérationnelles (SLO, error budget, RPO/RTO)
2. Blast radius et isolation (compte, VPC, AZ, namespace)
3. Chemin de déploiement (CI → registry → GitOps / pipeline)
4. Identité (OIDC, rôles courts) et secrets
5. Observabilité dès le jour 1 (logs, metrics, traces)
6. FinOps (tags, quotas, region fixe)

Le système est un contrat : latence p95, disponibilité, coût et toil.

Question jury	Réponse DEH attendue
Combien d’utilisateurs ?	Peak RPS + croissance 12 mois
Dispo cible ?	SLO (ex. 99.9 %) + error budget
Données ?	Volume, rétention, PII, chiffrement
Région ?	ca-central-1 (lab DEH)
Qui opère ?	App team + golden path

Étape 2 — Clarifier avant de dessiner

Huit réponses avant tout schéma :

1. Cas d’usage (API synchrone, batch, event-driven)
2. Trafic (RPS moyen / peak, taille payload)
3. SLO (disponibilité, latence p95/p99)
4. RPO / RTO (perte de données / temps de reprise)
5. Cohérence (fort vs éventuel)
6. Sécurité (authn/z, PII, PCI si paiements)
7. Contraintes (budget, stack imposée, multi-région ?)
8. Non-objectifs (ce qu’on ne construit pas au MVP)

Exemple brief lab : API paiements interne, 500 RPS peak, SLO 99.9 %, RPO 5 min, RTO 30 min, region ca-central-1, multi-AZ, pas de multi-région au MVP.

Étape 3 — Architecture de référence multi-AZ

Clients / partenaires
        │
        ▼
   [ CloudFront ]  (option — cache statique / WAF)
        │
        ▼
   [ ALB ]  ca-central-1  (multi-AZ)
        │
   ┌────┴────┐
   ▼         ▼
[ ECS/Fargate svc ]  ×N  (ou EKS Deployment)
   │         │
   ▼         ▼
[ ElastiCache Redis ]   [ RDS PostgreSQL Multi-AZ ]
   │
   ▼
[ SQS / EventBridge ] → workers (async : webhooks, settlements)
   │
   ▼
Observabilité : CloudWatch + (OTel) traces · alarms · runbooks
IAM : OIDC CI → rôles courts · tags Owner/Service/Env/CostCenter

Choix DEH pour le lab :

Bloc	Option MVP	Alternative
Compute	ECS Fargate	EKS (plus d’ops)
Entrée	ALB	API Gateway HTTP
Data	RDS Multi-AZ	Aurora (coût+)
Cache	Redis (ElastiCache)	Memcached
Async	SQS	EventBridge + Step Functions
Secrets	SSM / Secrets Manager	Vault / ESO (wow-vault)

La plateforme en fait un golden path (template + CI OIDC) — Platform Engineering 2026.

Étape 4 — Trade-offs à verbaliser

Axe	Option A	Option B	Quand
Cohérence	RDS synchrone	Eventual + outbox	Paiements → A
Scale	Scale vertical	Horizontal + queue	Peak → horizontal
Ops	Fargate	EKS	Petite équipe → Fargate
Dispo	Single-AZ	Multi-AZ	Prod → Multi-AZ
Latence	Sync DB	Cache + TTL	Lectures chaudes
Coût	Always-on	Spot / scale-to-0	Non-prod

Verbalisez : « On paie de la complexité ops pour gagner X ». Sans trade-off, ce n’est pas une décision.

Étape 5 — Estimations back-of-envelope

Hypothèses lab : 500 RPS peak, payload JSON ~2 KB, 70 % lectures.

Bande passante ≈ 500 × 2 KB ≈ 1 MB/s (OK ALB)
tasks ≈ ceil(500/50)=10 · pool DB/task 10 → ~100 connexions
Cache hit 80 % → charge lecture DB ÷ 5

Montrez le calcul et les hypothèses ; validez avec k6.

Étape 6 — Défaillances, blast radius, runbooks

Listez 5 pannes et la réponse :

Panne	Impact	Mitigation
AZ down	50 % tasks	Multi-AZ + capacity buffer
RDS primary fail	Writes bloqués	Multi-AZ failover (~RTO minutes)
Redis down	Latence ↑	Fallback DB + circuit breaker
Déploiement bad	Erreurs 5xx	Canary / rollback GitOps
Pics RPS ×3	Saturation	Autoscaling + queue async

Blast radius : mauvais IAM ou secret long = incident. Préférez OIDC CI et tags FinOps.

Étape 7 — Lab : design doc API paiements (ca-central-1)

Objectif : design doc d’1 page + identité AWS. Aucune ressource payante obligatoire.

7.1 — Identité lab

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity
aws configure get region

Attendu : ARN profil lab ; region ca-central-1.

7.2 — Scaffold design doc

mkdir -p design-lab-payments && cd design-lab-payments

cat > DESIGN.md << 'EOF'
# Design — payments-api (lab DEH)

## Contexte
API interne de paiements (autorisation + capture). Region : ca-central-1.

## Exigences
- Peak : 500 RPS · SLO : 99.9 % · p95 latence : < 200 ms
- RPO 5 min · RTO 30 min · Multi-AZ · Pas de multi-région MVP
- Auth : mTLS ou JWT interne · PII chiffrée at rest

## Architecture
Clients → ALB → ECS Fargate (payments-api) → RDS PostgreSQL Multi-AZ
                              ↘ Redis (idempotency + sessions courtes)
                              ↘ SQS (webhooks async)

## Décisions
- Fargate vs EKS : Fargate (équipe petite, moins de control plane)
- Sync writes DB ; async pour notifications partenaires
- Idempotency-Key obligatoire sur POST /charges

## Observabilité
- /health /ready · logs JSON · métriques RPS/5xx/latence
- Alarmes : 5xx > 1 %, p95 > 300 ms, CPU > 70 %
- Runbook : rollback image, failover RDS, purge cache

## Tags
Owner=team-payments Service=payments-api Env=nonprod CostCenter=platform-lab Region=ca-central-1

## Non-objectifs MVP
Multi-région active-active, ledger blockchain, console opérateur riche.
EOF

7.3 — Checklist entretien / review

• [ ] Exigences chiffrées (RPS, SLO, RPO/RTO)
• [ ] Schéma multi-AZ en ca-central-1
• [ ] Trade-offs écrits (compute, data, async)
• [ ] Estimation capacité (tasks, connexions DB)
• [ ] 5 modes de panne + mitigation
• [ ] Identité CI OIDC (pas de clés longues)
• [ ] Tags FinOps + /health
• [ ] Non-objectifs explicites
• [ ] Plan de cleanup si lab réel plus tard

7.4 — Optionnel

Déploiement réel plus tard : service-template + Trivy + Argo CD. Sinon DESIGN.md suffit.

Erreurs fréquentes

Erreur	Impact	Correction
Dessiner avant les SLO	Architecture décorative	Clarifier 8 questions d’abord
Single-AZ « pour simplifier »	Outage AZ = outage total	Multi-AZ dès le design prod
Oublier l’async	Timeouts partenaires	Queue + retries idempotents
Clés IAM longues en CI	Fuite credentials	OIDC + rôles courts
Region us-east-1 par habitude	Incohérence DEH / coût	Forcer ca-central-1
Pas d’observabilité	Debug au feeling	Métriques + alarmes + runbook
Sur-ingénierie EKS/mesh	Toil	Thinnest viable path

Quiz (5 questions)

1. En system design DevOps, la première étape est : – A. Choisir Kubernetes
– B. Clarifier SLO, trafic, RPO/RTO et non-objectifs
– C. Acheter un service mesh

2. Un SLO 99.9 % signifie surtout : – A. Zéro incident possible
– B. Un budget d’erreur mesurable (~43 min/mois)
– C. Un type d’instance EC2

3. Region lab DEH imposée : – A. us-east-1
– B. ca-central-1
– C. eu-west-3

4. Pour réduire le blast radius CI → AWS : – A. Access keys longues dans Git
– B. OIDC + assume-role à durée courte
– C. User root partagé

5. Un bon design doc inclut : – A. Uniquement un beau schéma
– B. Trade-offs, capacité, pannes, observabilité, non-objectifs
– C. Seulement le choix de langage

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

System design DevOps ≠ software ?

Moins d’algo, plus SLO, déploiement, identité, observabilité, coût, blast radius.

Faut-il forcément Kubernetes ?

Non. Fargate / App Runner gagnent souvent sur l’ops. EKS si multi-équipes ou GitOps dense.

Multi-région dès le MVP ?

Rarement. Multi-AZ en ca-central-1 couvre beaucoup de SLO 99.9 %.

Comment s’entraîner ?

35–45 min chrono : clarifier → schéma → trade-offs → capacité → pannes. Puis Entretien DevOps 2026.

Où placer Platform Engineering ?

Quand le design se répète : templates et guardrails → golden path.

Pourquoi ca-central-1 ?

Standard lab DevOps Elastic Hayway : tutos, IAM et FinOps alignés.

Pour aller plus loin

• Entretien DevOps 2026 (WOW 48)
• Portfolio GitHub DevOps (WOW 50)
• Platform Engineering 2026
• SRE error budgets · OpenTelemetry
• k6 · Multi-account
• Démarrer avec AWS

Maillage série WOW

← Précédent	Entretien DevOps 2026
→ Suivant	Portfolio GitHub DevOps
Aussi	Platform Engineering · SRE error budgets · OpenTelemetry · DevSecOps

---

Meta publication (SEO)

• Title SEO : System design pour DevOps / Platform (guide entretien FR)
• Meta description : System design DevOps & Platform : SLOs, multi-AZ ca-central-1, capacité, pannes, design doc lab API paiements. FAQ, quiz, check-list DEH.
• Focus keyword : system design devops
• Secondary : entretien system design, architecture plateforme, SLO DevOps
• Image : assets/web/devopelastichayway/cover-wow-system-design-devops-1200x630.webp (à générer)
• Catégorie : WOW / Platform · Niveau : Intermédiaire
• URL cible : https://devopelastichayway.com/tutoriels/wow-system-design-devops/
• Post live : N/A (nouveau) · slug wow-system-design-devops · Publish : HOLD (draft only — feu vert Maître requis)