Microservices, ou la frontière qu'on paie en réseauMicroservices, or the boundary you pay for in network

On découpe en services. Qu'est-ce qu'on achète, et qu'est-ce qu'on paie ?You split into services. What do you buy, and what do you pay?

Le #1 a tracé la frontière en logique ; ce numéro la transforme en frontière réseau. Le geste a l'air anodin — l'appel qui était en mémoire devient un appel HTTP — mais on l'écrit comme s'il restait une fonction locale : totale, instantanée, sûre. Or le réseau n'est pas une fonction. Ce qui varie d'un système à l'autre, ce n'est pas le nombre de services : c'est si l'on a une vraie raison de payer ce qu'ils coûtent. Le réflexe : nommer ce qu'on achète — le déploiement indépendant — et ce qu'on paie — le réseau devient le bug —, et n'extraire un service que lorsque la première colonne pèse plus lourd que la seconde.Issue #1 drew the boundary in logic; this one turns it into a network boundary. The move looks innocuous — the call that was in-memory becomes an HTTP call — but you write it as if it were still a local function: total, instant, safe. Yet the network is not a function. What varies between systems isn't the number of services: it's whether you have a real reason to pay what they cost. The reflex: name what you buy — independent deployment — and what you pay — the network becomes the bug —, and extract a service only when the first column outweighs the second.

# on "passe en microservices" : facturation devient un service à part.
# l'appel qui était en mémoire devient un appel réseau — mais on l'écrit pareil :
def checkout(order_id):
    price = http.get(f"http://billing/invoices/{order_id}").json()["amount"]
    #        ^^^^ traité comme un appel de fonction local : total, instantané, sûr
    charge(order_id, price)

# sauf que le réseau n'est PAS une fonction :
#   - il peut être lent (le service met 8s à répondre)
#   - il peut échouer à moitié (timeout : a-t-il facturé, oui ou non ?)
#   - il peut répondre deux fois (le retry double la charge)
# le déploiement indépendant, on l'a acheté. ces trois lignes, on les paie.

Le réseau devient le bug, et la transaction d'hier n'existe plus.The network becomes the bug, and yesterday's transaction is gone.

Découper en services avant d'en avoir besoin a trois coûts qui se renforcent. L'appel inter-services échoue de façons nouvelles : lenteur, timeout, panne partielle — et chaque appel local est devenu un point de défaillance qu'il faut prévoir. La cohérence forte disparaît : ce qui tenait dans une transaction de base de données (« débite ET marque payé, tout ou rien ») s'étale maintenant sur deux services qui peuvent diverger. Et l'observation se fragmente : un bug ne vit plus dans une stack trace mais dans une trace distribuée à travers cinq services, des logs éparpillés, des horloges qui ne s'accordent pas. Le réseau ne se contente pas d'ajouter de la latence ; il rend possibles des pannes qui n'existaient tout simplement pas.Splitting into services before you need them has three costs that reinforce each other. The inter-service call fails in new ways: slowness, timeout, partial failure — and every local call has become a failure point you must plan for. Strong consistency disappears: what held in a database transaction ('charge AND mark paid, all or nothing') now spreads across two services that can diverge. And observation fragments: a bug no longer lives in a stack trace but in a distributed trace across five services, scattered logs, clocks that don't agree. The network doesn't merely add latency; it makes possible failures that simply didn't exist.

def checkout(order_id):
    mark_paid(order_id)                                  # service commandes : OK
    resp = http.post("http://billing/charge", ...)       # 💥 timeout après 8s
    # le débit a-t-il eu lieu ? on n'en sait RIEN :
    #   - non → la commande est "payée" mais rien n'est débité
    #   - oui → on retente, et on débite le client DEUX fois
    # dans un monolithe, une transaction réglait ça. ici, c'est à nous de gérer.

On promeut la frontière logique en frontière réseau — et on en compte le prix.Promote the logical boundary to a network one — and count the price.

Un microservice, c'est une frontière logique qu'on a décidé de payer en réseau. L'animation part du monolithe modulaire où l'appel est en mémoire, coupe pour montrer ce qu'on achète — le déploiement indépendant —, fait traverser l'appel sur le fil pour montrer ce qu'on paie — lenteur, panne partielle, double réponse, fin de la transaction partagée —, puis pose la condition : la ligne ne se trace que si une douleur concrète en couvre le coût. On n'achète pas le réseau parce qu'il est moderne ; on l'achète quand son bénéfice dépasse son prix.A microservice is a logical boundary you decided to pay for in network. The animation starts from the modular monolith where the call is in-memory, cuts to show what you buy — independent deployment —, sends the call across the wire to show what you pay — slowness, partial failure, double answer, the end of the shared transaction —, then sets the condition: the line is drawn only if a concrete pain covers its cost. You don't buy the network because it's modern; you buy it when its benefit exceeds its price.

# un appel inter-services se traite comme faillible, pas comme une fonction locale▸ à toiyour turn — l'appel qui traverse le réseau — que demande commandes à facturation ?the call that crosses the network — what does orders ask billing? · cliquer pour révélerclick to reveal                      idempotency_key=order_id,   # rejouable sans double débit (Vol 7)▸ à toiyour turn — borner l'attente pour ne pas figer sur un service lent — quel garde ?bound the wait so a slow service can't freeze you — which guard? · cliquer pour révélerclick to reveal# et la cohérence "payé + débité" n'est plus une transaction : c'est une saga,
# avec une compensation si l'un des deux côtés échoue. le réseau impose ce surcoût.

Plus de services n'est pas mieux. La granularité qu'on n'a pas méritée.More services isn't better. The granularity you didn't earn.

Le piège n'est pas le microservice — c'est d'en faire un par entité technique, sans qu'aucune douleur ne le justifie. On découpe « commande », « utilisateur », « adresse », « prix », « taxe » en services distincts parce que « c'est l'architecture », et afficher une seule commande devient sept appels réseau en cascade : si l'un expire, la page tombe. Ces services changent toujours ensemble et se déploient ensemble — on a donc la latence et les pannes du réseau sans le déploiement indépendant qu'on était censé acheter. La granularité fine ne rend pas le système modulaire ; elle distribue son couplage. Bascule le toggle : compte les appels réseau qu'exige une seule action utilisateur.The trap isn't the microservice — it's making one per technical entity, with no pain to justify it. You split 'order', 'user', 'address', 'pricing', 'tax' into separate services because 'it's the architecture', and showing a single order becomes seven cascading network calls: if one times out, the page falls. These services always change together and deploy together — so you have the latency and failures of the network without the independent deployment you were supposed to buy. Fine granularity doesn't make the system modular; it distributes its coupling. Flip the toggle: count the network calls one user action demands.

# on extrait UN service, pour une douleur réelle, et on traite le réseau comme faillible
# facturation : équipe dédiée, charge à isoler → la ligne réseau se justifie
class OrdersService:
    def checkout(self, order_id):
        try:
            billing.charge(order_id, amount,
                           idempotency_key=order_id,   # rejouable sans double débit
                           timeout=2.0)                 # on borne l'attente
        except BillingTimeout:
            saga.compensate(order_id)                   # la cohérence est gérée, pas supposée
# une frontière, un vrai motif (équipe + charge), un appel pensé comme pouvant échouer.

Des services par défaut, ou une frontière réseau qu'on a achetée.Services by default, or a network boundary you actually bought.

Quand ne pas découper en servicesWhen not to split into services

Le microservice s'achète, et le réseau se paie à chaque appel. On reste en monolithe (modulaire) — et c'est presque toujours correct au départ — quand :The microservice is bought, and the network is paid at every call. Stay in a (modular) monolith — and that's almost always right at first — when:

• une seule équipe tient le produit : le déploiement indépendant n'a aucune valeur s'il n'y a personne à débloquer. Le bénéfice principal du microservice — des équipes qui ne se gênent plus — ne s'achète que quand la gêne existe.a single team owns the product: independent deployment has no value if there's no one to unblock. The microservice's main benefit — teams no longer stepping on each other — is bought only when the stepping-on exists.
• la charge tient sur un déployable : tant qu'on n'a pas un composant dont le profil de charge diffère radicalement du reste, scaler le monolithe entier est plus simple et moins cher que d'isoler un service.the load fits on one deployable: until you have a component whose load profile differs radically from the rest, scaling the whole monolith is simpler and cheaper than isolating a service.
• les coutures ne sont pas encore stables : sur un produit jeune, les frontières bougent à chaque sprint. Les figer en réseau, c'est payer une migration distribuée à chaque erreur de découpe. Laisse-les se révéler en logique d'abord.the seams aren't stable yet: on a young product, boundaries move every sprint. Freezing them in network means paying a distributed migration for every wrong cut. Let them reveal themselves in logic first.

Le réflexe n'est donc pas « découpe en microservices, c'est scalable » : c'est « ai-je une douleur concrète — une équipe, une charge, une techno — que seule une frontière réseau soulage ? Alors j'extrais ce service-là. Sinon, le monolithe modulaire reste plus sain. »So the reflex isn't 'split into microservices, it scales': it's 'do I have a concrete pain — a team, a load, a tech — that only a network boundary relieves? Then I extract that one service. Otherwise, the modular monolith stays healthier.'

Mot de l'éditeurFrom the editor

Ce numéro prend volontairement le contre-pied de la mode : on ne commence presque jamais en microservices. La leçon du volume tient en deux colonnes — ce qu'on achète (le déploiement indépendant, réponse à un problème d'organisation) et ce qu'on paie (le réseau devient le bug : lenteur, panne partielle, double réponse, fin de la transaction). Un microservice n'est pas une frontière plus propre qu'un module ; c'est la même frontière, qu'on a décidé de payer en réseau parce qu'une douleur réelle l'exigeait. Le découper sans cette douleur, ou par entité technique, ne rend rien modulaire : ça distribue le couplage — le monolithe distribué qu'on aura nommé deux fois pour mieux le fuir.This issue deliberately goes against the fashion: you almost never start in microservices. The volume's lesson fits in two columns — what you buy (independent deployment, an answer to an organizational problem) and what you pay (the network becomes the bug: slowness, partial failure, double answer, the end of the transaction). A microservice isn't a cleaner boundary than a module; it's the same boundary, which you decided to pay for in network because a real pain demanded it. Splitting it without that pain, or by technical entity, makes nothing modular: it distributes the coupling — the distributed monolith we'll have named twice the better to flee it.

Avec lui se referme le Vol 6 — découper le système : le #1 a posé la frontière logique comme défaut sain, le #2 a montré ce qu'il en coûte de la promouvoir en frontière réseau. Mais une fois la ligne réseau tracée, une question reste entière, et c'est tout le Vol 7 : qu'est-ce qui se passe quand l'autre côté ne répond pas — ou répond deux fois ? On a vu le timeout sans réponse, le retry qui double un débit, la transaction qui n'existe plus. La résilience dans le distribué — retry, timeout, backoff, idempotence, circuit breaker, saga — est l'art de rendre normal ce que le réseau rend inévitable : l'échec partiel.With it Vol 6 closes — splitting the system: #1 laid the logical boundary as the healthy default, #2 showed what it costs to promote it to a network boundary. But once the network line is drawn, a question remains whole, and it's all of Vol 7: what happens when the other side doesn't answer — or answers twice? We've seen the answerless timeout, the retry that doubles a charge, the transaction that's gone. Resilience in the distributed world — retry, timeout, backoff, idempotency, circuit breaker, saga — is the art of making normal what the network makes inevitable: partial failure.

Les voisins que ce numéro débloqueThe neighbors this issue unlocks

• SOA — l'ancêtre des microservices : découper le système en services orientés métier, mais souvent autour d'un bus central (ESB) lourd. Les microservices en gardent l'idée — des services à frontière métier — en rejetant le point central : chaque service est autonome, la logique vit aux extrémités, pas dans le tuyau.microservices' ancestor: splitting the system into business-oriented services, but often around a heavy central bus (ESB). Microservices keep the idea — services with a business boundary — while rejecting the central point: each service is autonomous, logic lives at the ends, not in the pipe.
• Service mesh — l'infrastructure qui rend le réseau inter-services gérable : un proxy à côté de chaque service prend en charge retry, timeout, mTLS, observation, sans que le code métier les porte. La réponse opérationnelle aux coûts du chapitre 2 — utile précisément quand on a assez de services pour que ces coûts pèsent.the infrastructure that makes the inter-service network manageable: a proxy beside each service handles retry, timeout, mTLS, observation, without the business code carrying them. The operational answer to chapter 2's costs — useful precisely when you have enough services for those costs to weigh.
• Distributed monolith — l'anti-pattern nommé au #1 et confirmé ici : des services déployés séparément mais qui changent et se déploient toujours ensemble. Tous les coûts du réseau, aucun bénéfice. Le voisin qu'on cite pour le reconnaître tôt — c'est lui qui guette dès qu'on découpe sans couture ou avant la douleur.the anti-pattern named in #1 and confirmed here: services deployed separately but that always change and deploy together. All the network's costs, no benefit. The neighbor you cite to recognize it early — it lurks the moment you split without a seam or before the pain.

Le kata de décision — franchir le réseau, ou pas ?The decision kata — cross the network, or not?

Rien à implémenter : le geste qui ancre, c'est de trancher — et de nommer la douleur qui paie le réseau. Trois situations. Pour chacune, parie avant de dérouler : rester en monolithe modulaire, ou extraire un service ? Rappel du quadrant : séparer le déploiement ne rend pas modulaire — c'est un autre axe. La dernière question est la sournoise : elle porte sur l'ordre, monolithe d'abord ou microservices d'emblée ?Nothing to implement: the anchoring gesture is deciding — and naming the pain that pays for the network. Three situations. For each, bet before you scroll: stay a modular monolith, or extract a service? Quadrant reminder: separating deployment doesn't make you modular — that's a different axis. The last question is the sneaky one: it's about order, monolith first or microservices from the start?

# Le fil du Vol 6 : deux axes indépendants — modularité (design) × déploiement.
# La bonne case par défaut : haute modularité, UN déployable (le monolithe modulaire).
# Pour chaque situation : rester monolithe modulaire, ou franchir le réseau ?

SITU_A : monolithe modulaire sain · 1 équipe de 5 · charge homogène · coutures nettes
SITU_B : 3 équipes se marchent dessus sur un même déployable · déploiement = file d'attente
SITU_C : produit neuf · coutures encore inconnues · tenté de « démarrer en microservices »