À 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

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)

← Catalogue Tutoriels

Pour aller plus loin — hubs live

Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.

© 2023 devopelastichayway.com All rights reserved.