TL;DR. Le loop backend 2026 ne se joue plus sur LeetCode mais sur system design, choix de BDD et résilience. PostgreSQL est utilisé par 49 % des dev (Stack Overflow 2024) et 55 % des boîtes subissent des outages hebdomadaires (Cockroach Labs 2025). Sharding, replication, caching et queues pèsent désormais plus lourd qu'un O(log n) parfait.
Un handbook visuel back-end vient de buzzer sur Hacker News cette semaine. Et il met le doigt sur ce que les recruteurs testent vraiment en 2026.
Côté Amazon, un candidat raconte sur HN en mai 2026 que le LeetCode pur recule, et que le system design + les questions BDD montent en pondération.
La vraie question, c'est : tu sais expliquer en 5 minutes pourquoi tu choisirais Postgres plutôt que DynamoDB pour un service à 10k QPS — et où ça casse ?
Pourquoi le loop backend 2026 ne ressemble plus à 2022
Le shift est net depuis l'arrivée des assistants IA en mainstream. Amazon et plusieurs BigTech évaluent désormais l'usage assumé de Claude/Copilot sur des tâches à scope large, plus seulement la complexité algo en chambre.
Un témoignage sur Hacker News (item 48101373) résume la nouvelle doctrine :
"The interview is an information-gathering session, not a workday simulation. So it makes sense to test your fundamentals even if AI changes the day-to-day."
Conséquence pratique : tes fondamentaux backend (BDD, scalabilité, résilience) deviennent le vrai filtre. L'IA gère les boilerplates, le recruteur veut savoir si tu comprends ce qui se passe sous le capot.
Tu vas continuer à voir un round LeetCode-style — c'est juste qu'il ne fait plus 60 % de la note. Le centre de gravité a glissé vers les rounds system design et le deep-dive BDD.
System design backend : la grille en 6 axes à dérouler
Sur un round de 45-60 minutes, les recruteurs notent ta capacité à structurer plus que ta réponse finale. Voici la grille à dérouler systématiquement, inspirée du System Design Primer de Donne Martin (280k+ stars sur GitHub) et des conseils de Jacob Brazeal (2025).
- Clarifier les exigences. RPS attendu, latence p99, SLA, taille du dataset, ratio lecture/écriture. Ne saute jamais cette étape.
- API design. Endpoints REST/gRPC, payloads, idempotence, versioning. 10 minutes max.
- Data model. Tables/collections, clés, index, contraintes. C'est là que ton choix de BDD se joue.
- Scaling. Vertical d'abord (plus simple), horizontal ensuite (sharding, replication).
- Résilience. Failover, retries, circuit breakers, dégradation gracieuse.
- Observabilité. Metrics, logs, traces, alertes, SLO.
Le piège classique : foncer sur le diagramme avant d'avoir clarifié les non-functional requirements. Tu dessines pendant 20 minutes un truc qui ne correspond à rien.
Prends les 5 premières minutes pour poser des questions. Les recruteurs adorent ça — c'est la marque d'un senior.
SQL vs NoSQL en entretien : justifier ton choix de BDD
Le Stack Overflow Developer Survey 2024 donne le palmarès sans appel : PostgreSQL 49 %, MySQL 40,3 %, Redis 20 %. Ces trois-là, tu dois savoir pourquoi ils dominent.
Quand choisir SQL ? Transactions ACID, jointures complexes, intégrité référentielle, schéma stable. 80 % des cas réels, soyons honnêtes.
Quand choisir NoSQL ? Scale horizontal natif, schéma flexible (documents), write-heavy avec accès par clé. Cas typiques : event store, profils utilisateurs très imbriqués, time-series.
Pour structurer la réponse, reprends les 4 modèles canoniques du livre de Martin Kleppmann (DDIA 2e édition, O'Reilly 2025) :
- ✓Modèle : tables + jointures, ACID strict
- ✓Cohérence : forte par défaut
- ✓Scale : vertical d'abord, sharding manuel
- ✓Cas d'usage : transactions, schéma stable, 80 % des projets
- ✗Modèle : documents, clé-valeur, colonnes larges
- ✗Cohérence : souvent éventuelle (quorum R+W>N)
- ✗Scale : horizontal natif, sharding intégré
- ✗Cas d'usage : event store, profils imbriqués, time-series
- Relationnel (Postgres, MySQL) : jointures, ACID, schéma rigide.
- Document (MongoDB, DynamoDB) : objets imbriqués, schéma souple.
- Graph (Neo4j) : relations many-to-many denses.
- Wide-column (Cassandra, ScyllaDB) : write-heavy, time-series.
Le piège : répondre "ça dépend" sans cadre. Donne 2 ou 3 critères de décision concrets — pattern d'accès, volume, contraintes de cohérence — et tranche.
Sharding, replication, caching : les 3 leviers de scalabilité
Une fois que tu as posé le data model, le recruteur va pousser sur la scalabilité. Trois leviers à maîtriser comme ton prénom.
Sharding. Hash (distribution uniforme, rebalancing pénible), range (range queries efficaces, hot partitions), geo (latence locale, cohérence cross-region difficile). Tu dois savoir choisir la clé et anticiper le rebalancing.
Replication. Leader-follower (le défaut, simple), multi-leader (multi-region, conflits à résoudre), leaderless type Dynamo (quorum R+W>N). Le trade-off central : cohérence vs latence vs disponibilité (le fameux PACELC).
Caching. Redis domine (20 %, Stack Overflow 2024). Trois questions à anticiper : stratégie (cache-aside vs write-through vs write-back), invalidation (le "hard problem"), TTL.
Et le lien avec la résilience est direct : 55 % des boîtes ont des outages hebdomadaires et 14 % quotidiens (Cockroach Labs 2025). Les loops testent donc le failover et la dégradation gracieuse, pas que le happy path.
Queues, événementiel et microservices : ce que les seniors attendent
Sur un loop senior, on attend que tu cites les patterns par leur nom : pub/sub, work queue, event sourcing, CQRS, saga. Pas pour faire le malin — pour montrer que tu connais le vocabulaire des architectes.
Un témoignage classique sur Hacker News (item 43993982) résume le stack 2025-2026 :
"Kafka for communication between microservices, and MQTT (VerneMQ) for IOT devices — Sidekiq, Sidekiq, Sidekiq (or just Postgres if I'm dealing with something trivial)."
La question piège qui arrive 8 fois sur 10 : "Et si Kafka tombe ?". La bonne réponse cite trois choses :
- DLQ (Dead Letter Queue) pour les messages non traitables.
- Idempotence côté consumer (clé d'idempotence, dédoublonnage).
- At-least-once vs exactly-once : exactly-once est un mensonge, sauf via transactions Kafka avec idempotent producers — assume at-least-once et rends tout idempotent.
Si tu sors ces trois concepts proprement, tu passes le filtre senior.
Résilience, SLO et observabilité : le filtre senior 2026
C'est là que beaucoup de candidats sautent l'avion. Le rapport Cockroach Labs State of Resilience 2025 (via InfoQ) est sans appel : 100 % des participants ont subi des pertes de revenu liées aux outages, et 8 % rapportent des pertes ≥ 1 M USD sur 12 mois.
Ce que les loops attendent sur ce volet :
- Circuit breakers (Hystrix-style, ou Resilience4j) pour stopper les cascades.
- Retries avec backoff exponentiel + jitter — jamais de retry naïf en boucle.
- Bulkheads pour isoler les pools de threads/connexions.
- Chaos engineering au moins en concept (Gremlin, Litmus).
- SLO + error budgets : 99,9 % de dispo = 43 min/mois de budget d'incident.
Sur l'observabilité, la formule magique : 3 piliers (metrics, logs, traces) + 4 Golden Signals (latency, traffic, errors, saturation). Cite OpenTelemetry, Prometheus, Grafana, et idéalement un cas réel où un dashboard t'a sauvé.
Le piège ultime : oublier l'observabilité dans ton diagramme system design. C'est disqualifiant en senior — un système sans observabilité ne se débugue pas en prod.
Questions fréquentes
Le LeetCode est-il mort pour les entretiens backend en 2026 ?
Non, mais il recule clairement. Amazon (témoignage HN, mai 2026) et d'autres rééquilibrent vers system design + scope large + usage assumé de l'IA. Le LeetCode reste un filtre d'entrée, plus le cœur du loop.
Combien de temps prévoir pour préparer un loop backend senior ?
4 à 8 semaines à raison d'une heure par jour : 40 % system design, 30 % BDD et scalabilité, 20 % algo, 10 % behavioural. Plus court si tu pratiques déjà ces sujets au quotidien dans ton job.
Quelle base de données choisir par défaut en system design interview ?
PostgreSQL, sauf justification explicite. C'est la base la plus utilisée au monde (49 %, Stack Overflow 2024) et elle couvre 80 % des cas : relationnel pur, JSONB, full-text, géospatial.
Faut-il connaître Kafka pour un entretien backend en 2026 ?
Oui, au moins conceptuellement : topics, partitions, consumer groups, offsets, DLQ, idempotence. Alternatives à connaître : RabbitMQ, NATS, SQS.
Comment répondre à une question de sharding sans se planter ?
Démarre par la clé de sharding (hash, range, geo), expose le trade-off rebalancing vs hot partitions, cite un cas concret. Reste honnête sur les limites — l'examinateur attend de la nuance.
Les loops backend testent-ils vraiment la résilience ou c'est du bonus ?
C'est central en senior. 55 % des entreprises subissent des outages hebdomadaires (Cockroach Labs 2025), donc retries, circuit breakers et failover sont attendus dès le diagramme initial.
Quelle différence entre cache-aside et write-through ?
Cache-aside : l'app lit le cache, fallback DB, puis remplit le cache. Write-through : chaque écriture passe d'abord par le cache puis la DB. Cache-aside est plus simple, write-through offre une cohérence plus forte mais ralentit les écritures.
Comment parler d'observabilité sans bullshit ?
Trois piliers (metrics, logs, traces) + quatre Golden Signals (latency, traffic, errors, saturation) + SLO et error budgets. Cite Prometheus, Grafana, OpenTelemetry, et un cas où tu as détecté un incident grâce à un dashboard.
Le candidat peut-il utiliser ChatGPT pendant l'entretien backend ?
Ça dépend des boîtes : Amazon teste désormais l'usage d'IA sur des tâches à scope large (HN 2026), d'autres l'interdisent strictement. Demande explicitement la règle au recruteur avant la session.
Quel livre lire en priorité avant un loop backend senior ?
Designing Data-Intensive Applications, 2e édition de Martin Kleppmann (O'Reilly 2025). C'est la bible citée dans la quasi-totalité des prep guides senior.
Ce qu'on retient
- Le loop backend 2026 = system design + BDD + résilience, pas LeetCode pur.
- PostgreSQL (49 %) est la réponse par défaut ; justifie chaque écart.
- Maîtrise les 6 axes du system design : exigences, API, data, scale, failover, observabilité.
- Sharding, replication, caching : connais les trade-offs, pas seulement les noms.
- Queues (Kafka, Sidekiq) + idempotence = filtre senior incontournable.
- 55 % des boîtes ont des outages hebdo → la résilience est un critère de notation.
- Lis DDIA 2e édition et entraîne-toi à voix haute, en 45 min chronos.
Et avant même le loop : assure-toi que ton CV met en avant les bons signaux scalabilité et résilience avec l'analyse de CV Velyq. Un CV qui ne parle que de "framework X, framework Y" sans charge ni SLA passe sous le radar des recruteurs backend en 2026.
