Étude de cas Amazon : du monolithe Obidos à l’architecture orientée services

Introduction

Amazon est l'un des cas les plus utiles pour comprendre l'évolution des architectures modernes, précisément parce que son histoire ne se réduit pas au slogan “monolithe contre microservices”. Le cas documenté parle plutôt d'une plateforme de commerce en ligne qui commence avec une architecture centralisée efficace, puis découvre que la croissance du domaine, des données et de l'organisation rend le couplage de plus en plus coûteux.

La formulation prudente est donc la suivante : Amazon illustre surtout la transition d'un système monolithique / centralisé vers une architecture orientée services, puis vers une culture de systèmes distribués à grande échelle. Les termes “microservices” et “systèmes distribués” peuvent aider à analyser cette trajectoire, mais ils ne doivent pas être plaqués rétroactivement sur chaque étape historique.

La vraie question n'est pas : faut-il choisir un monolithe ou des microservices ? Elle est : quand la complexité d'un système justifie-t-elle le coût d'une architecture distribuée ?

Cette étude distingue trois niveaux : les faits documentés par Amazon, Werner Vogels ou AWS ; les interprétations architecturales raisonnables qui permettent de comprendre les compromis ; puis les leçons applicables aujourd'hui à une équipe DevOps, SRE, Platform Engineering ou backend senior.

Résumé exécutif

• Amazon a commencé avec une architecture centralisée qui permettait d'aller vite dans un domaine encore en forte découverte.
• Werner Vogels décrit Obidos comme l'application monolithique stateless qui servait les pages Amazon.com dans une architecture initialement deux-tiers. [S1]
• Le manifeste de 1998 indique que l'application accédait directement à plusieurs bases partagées liées aux produits, clients, pays, catégories et autres parties du modèle métier. [S2]
• Cette architecture était rationnelle au départ : moins de coordination distribuée, transactions plus simples, un chemin court entre application et données.
• Avec la croissance, le couplage entre code applicatif, modèles de données et responsabilités métier est devenu un frein : les bases partagées et les accès directs rendaient l'évolution plus difficile. [S1][S2]
• Le Distributed Computing Manifesto de 1998 formalise une direction : interfaces claires, services propriétaires, séparation présentation / logique métier / stockage, et réduction du couplage aux bases. [S2]
• La leçon moderne n'est pas de distribuer tôt. Elle est de surveiller les signaux de couplage durable, de clarifier les frontières métier, puis d'extraire uniquement ce qui justifie vraiment le coût opérationnel de la distribution.

Le contexte métier d'Amazon

Le contexte métier est essentiel. Amazon n'était pas seulement une application web qui affichait des pages. C'était une plateforme de commerce en ligne : catalogue produit, catégories, navigation, clients, commandes, paiement, pays, opérations et expansion continue de l'offre. Le système devait soutenir la croissance du trafic, l'élargissement du catalogue et une capacité d'innovation rapide.

Les sources publiques ne donnent pas un plan interne complet de chaque sous-système retail des années 1990. Il faut donc rester prudent : on peut parler des domaines visibles et des problèmes mentionnés par le manifeste, mais pas inventer de métriques, de topologies internes ou de séquences de migration non publiées.

Ce qui est documenté suffit déjà à comprendre le problème architectural : une application centrale, plusieurs bases de données partagées et un modèle de développement où de nombreuses fonctionnalités dépendaient directement du modèle de données. À petite échelle, ce modèle est efficace. À grande échelle, il crée un coût de changement qui augmente plus vite que la taille du code.

L'architecture initiale

Dans sa rétrospective, Werner Vogels explique qu'Amazon a commencé avec une architecture deux-tiers : un frontend monolithique stateless nommé Obidos et des bases de données. Le manifeste de 1998 décrit un système dans lequel les applications touchent directement les bases et où les données sont utilisées par plusieurs parties du système. [S1][S2]

[Clients]
    |
[Obidos - application monolithique stateless]
    |
[Databases partagees : produits, categories, clients, pays, etc.]

Le terme important ici est “centralisée”. Le système n'était pas nécessairement un bloc illisible sans aucune structure interne. Les sources publiques ne permettent pas de le qualifier précisément de “monolithe modulaire”. En revanche, elles documentent une application centrale et des dépendances fortes aux bases partagées.

Définitions rapides

• Monolithe : application déployée comme une unité principale, où plusieurs responsabilités métier vivent dans le même artefact ou le même runtime.
• SOA, ou architecture orientée services : approche où des capacités métier sont exposées via des services et des interfaces explicites, souvent avant l'usage moderne du terme microservices.
• Microservices : petits services déployables indépendamment, organisés autour de capacités métier, avec ownership d'équipe, contrats explicites et idéalement données décentralisées. [S11]
• Couplage : dépendance qui fait qu'un changement local force des changements ailleurs, parfois dans des zones que l'équipe ne maîtrise pas.

Détails techniques publiquement vérifiables

Pour un lecteur technique, la question naturelle est : quel était le stack exact ? Langages, frameworks, bases, orchestrateur, middleware ? La réponse sérieuse est partielle. Les sources publiques donnent quelques indices utiles, mais elles ne publient pas une cartographie complète du runtime Amazon retail de l'époque.

Le manifeste précise lui-même qu'il ne choisit pas la technologie d'implémentation de la nouvelle architecture. C'est un détail important : le document est d'abord un changement de modèle architectural, pas une RFC de framework. Il décrit les frontières, les interfaces et les workflows avant de choisir les outils. [S2]

Le détail le plus concret côté langage est la mention de nombreux scripts Perl ad hoc qui accédaient aux données métier. Ce point est architecturalement important : le problème n'était pas seulement Obidos, mais aussi l'écosystème de scripts et d'applications dépendant directement du modèle de données. [S2]

Côté base de données, les sources du manifeste parlent de bases partagées sans donner une liste produit exhaustive pour 1998. En revanche, AWS a documenté beaucoup plus tard la migration d'Amazon Consumer hors d'Oracle vers plusieurs services AWS, dont DynamoDB, Aurora, Amazon RDS et Redshift. Cette information éclaire la trajectoire moderne du parc de données Amazon, mais ne doit pas être rétroprojetée sans nuance sur l'architecture Obidos initiale. [S17]

Pourquoi cette architecture était logique au départ

Un monolithe n'est pas une erreur au départ. Au contraire, c'est souvent la manière la plus économique de découvrir un domaine, de livrer vite et de garder une cohérence globale. Quand une équipe peut encore comprendre le système entier, le coût d'une architecture distribuée est rarement justifié.

Une architecture centralisée réduit la surface opérationnelle : moins de réseaux internes, moins de contrats versionnés, moins de modes de panne partielle, moins de plateformes de messaging, moins de coordination entre runtimes. Elle simplifie aussi les transactions et l'accès aux données, parce que le code peut souvent lire et écrire directement ce dont il a besoin.

Dans une phase initiale, ces propriétés sont des avantages. Le problème apparaît quand la même simplicité locale devient une rigidité globale. Le monolithe devient dangereux non parce qu'il est un monolithe, mais parce que son couplage dépasse la capacité de l'organisation à raisonner, tester, déployer et faire évoluer le système.

Les signaux de douleur

Les signaux décrits autour d'Amazon en 1998 ne relèvent pas d'une simple préférence technique. Le manifeste parle d'une difficulté structurelle : les applications sont couplées aux bases de données, les modèles de données deviennent plus difficiles à faire évoluer, et la croissance du business multiplie les interactions entre domaines. [S2]

• Les bases de données partagées deviennent des points de coordination : chaque changement de schéma ou de sémantique peut affecter plusieurs consommateurs.
• L'accès direct aux données crée un couplage silencieux : une application dépend non seulement d'une information, mais de la forme exacte des tables et de leurs conventions.
• Le modèle de données devient plus difficile à faire évoluer parce que plusieurs fonctionnalités s'appuient sur les mêmes structures internes.
• L'innovation ralentit : un changement local demande davantage d'analyse d'impact, de tests transverses et de coordination.
• Le risque augmente : une modification destinée à une catégorie, un pays, un produit ou un parcours client peut toucher d'autres zones du système.

Aucune source publique fiable ne permet d'associer ces douleurs à des métriques précises comme un nombre de déploiements, un temps de build ou un incident spécifique. L'analyse doit donc rester qualitative.

Le Distributed Computing Manifesto de 1998

Le Distributed Computing Manifesto est important parce qu'il montre un moment rare : une grande entreprise qui formalise, très tôt, les problèmes du couplage entre applications et données, puis propose une direction de transformation. Werner Vogels a publié le document en 2022 en expliquant son contexte historique. [S1]

Le manifeste, daté de 1998, ne dit pas simplement “adoptons des microservices”. Ce vocabulaire n'était pas celui du moment. Il parle plutôt d'une architecture distribuée, de services qui masquent les détails de stockage, d'interfaces stables et d'une séparation plus nette entre présentation, logique métier et données. [S2]

Un point clé du document est la réduction des accès directs aux bases d'autres domaines. L'idée moderne peut se résumer ainsi : les applications ne devraient pas dépendre du schéma interne de données qu'elles ne possèdent pas ; elles devraient passer par une interface contrôlée par le propriétaire du domaine.

Le document est aussi très concret sur la forme attendue des interactions. Il distingue les appels synchrones pour les opérations à réponse immédiate, les opérations asynchrones où le résultat n'est pas attendu tout de suite, puis deux modèles de retour : polling et callback. Il anticipe déjà des problèmes que les plateformes modernes rencontrent encore : disponibilité du demandeur, surcharge du polling, état d'une opération en cours et suivi de workflow. [S2]

Le manifeste parle également de workflow distribué, de message-oriented middleware, de publish/subscribe pour propager des changements d'attributs, de state change rows pour suivre l'évolution d'un workflow, de data domains pour séparer customers, vendors et catalog, et de queues ou aggregation queues pour certains traitements de distribution center. Ces termes sont très proches du vocabulaire moderne event-driven, même si les technologies concrètes de l'époque ne sont pas celles d'aujourd'hui. [S2]

Ce document est précieux parce qu'il décrit une transformation progressive vers des services, pas une injonction dogmatique à tout découper.

Le passage vers une architecture orientée services

Le passage vers une architecture orientée services répond à une question simple : comment permettre à plusieurs parties du système d'évoluer sans que chaque changement devienne un événement transversal ? La réponse proposée consiste à introduire des interfaces explicites entre domaines.

• Service ownership : un service a un propriétaire clair, responsable de son contrat, de son comportement et de son exploitation.
• Interfaces explicites : les consommateurs appellent une API ou publient un événement au lieu de lire directement une table interne.
• Séparation des responsabilités : la présentation, la logique métier et le stockage cessent d'être fusionnés dans un seul modèle de changement.
• Masquage du stockage : le service peut changer son modèle interne sans casser tous les consommateurs, si le contrat reste stable.
• Évolution indépendante : une équipe peut faire évoluer sa capacité métier avec moins de coordination globale.

Cette trajectoire préfigure beaucoup de principes aujourd'hui associés aux microservices, mais il serait imprudent de dire qu'Amazon a simplement “inventé les microservices”. Ce que les sources montrent, c'est une évolution vers des services, des contrats et une culture opérationnelle distribuée.

Données et ownership

Le point le plus important de cette histoire n'est pas la taille des services. C'est la donnée. Une base partagée paraît pratique parce qu'elle évite de dupliquer des informations et donne un accès immédiat aux tables. Mais elle transforme rapidement le stockage en API implicite.

Quand une application lit directement une table d'un autre domaine, elle dépend de noms de colonnes, de conventions, de contraintes, d'index, de valeurs nulles et de significations métier qui peuvent changer. Le propriétaire de la donnée perd la capacité de faire évoluer son modèle sans négocier avec tous les consommateurs.

Ancien modele
-------------
Application
    |
    v
Base partagee

Nouveau modele
--------------
Application
    |
    v
Service proprietaire
    |
    v
Donnees controlees par le service

La leçon moderne est claire : un service doit posséder ses données, ou au minimum contrôler l'accès à son modèle. Cela ne signifie pas qu'aucune donnée ne soit jamais répliquée, projetée ou partagée. Cela signifie que le modèle interne ne doit pas devenir un contrat sauvage que tout le monde peut consommer. Les recommandations AWS sur la gestion distribuée des données dans les microservices vont dans ce sens. [S9]

Grille de lecture

Ancien modele : Application -> base partagee
Risque        : couplage au schema, coordination, regressions transverses

Nouveau modele : Application -> service proprietaire -> donnees
Benefice       : contrat explicite, evolution interne, ownership
Nouveau cout   : latence, versioning, observabilite, resilience

Communication entre services

Dès qu'un système devient distribué, la communication cesse d'être un détail d'implémentation. Un appel local devient un appel réseau. Un accès direct à une table devient une API. Une transaction simple peut devenir un workflow. Les erreurs réseau, la latence et les pannes partielles entrent dans le modèle de conception.

• Les appels synchrones sont utiles pour des réponses immédiates, mais ils propagent la latence et peuvent créer des chaînes de dépendances.
• Les APIs internes rendent les contrats visibles, mais elles exigent versioning, compatibilité, timeouts et discipline d'évolution.
• Le messaging et les événements découplent producteurs et consommateurs, mais introduisent ordre, duplication possible, backlogs et sémantique de traitement.
• L'orchestration centralise la logique d'un workflow ; la chorégraphie laisse les services réagir à des événements. Les deux modèles ont des coûts de lisibilité et de contrôle.
• Les retries doivent être bornés et conçus avec backoff, jitter et idempotence ; sinon ils aggravent une surcharge au lieu de la corriger. [S3][S4]

Les publications AWS modernes ne présentent pas la distribution comme gratuite. Elles insistent sur les timeouts, le backoff, l'idempotence, la visibilité opérationnelle et la gestion des files. C'est exactement le coût caché que beaucoup d'équipes sous-estiment quand elles copient un modèle microservices sans en adopter les garde-fous. [S3][S4][S5][S6]

Workflows et processus métier

Une plateforme de commerce a des processus longs. Une commande peut impliquer validation du panier, paiement, réservation de stock, préparation, livraison, notification, remboursement et support. Ces étapes n'ont pas toutes les mêmes propriétaires, les mêmes garanties de délai ni les mêmes modes de panne.

Dans un gros système centralisé, le risque est de cacher ces workflows dans du code applicatif couplé. Cela peut fonctionner pendant longtemps, mais plus le domaine grandit, plus il devient difficile de comprendre ce qui se passe quand une étape échoue, se répète ou arrive en retard.

Une architecture orientée services oblige à rendre ces processus explicites. Les frontières, événements, contrats, statuts et compensations deviennent des objets de conception. Ce n'est pas seulement plus technique ; c'est plus honnête sur la nature réelle du métier.

Le manifeste donne des exemples plus précis que “commande” au sens générique. Il parle d'un order pipeline, de customer_orders dont l'attribut condition détermine l'activité suivante, de charge processing pour les cartes de crédit, de picklists, de distributor shipments, de received_items et d'un suivi d'état consultable par le service client. Ces détails montrent que l'enjeu était déjà celui des workflows longs, observables et partiellement asynchrones. [S2]

[Checkout]
    |
    v
Commande creee
    |
    +--> [Paiement] --------> Paiement autorise / refuse
    |
    +--> [Preparation] -----> Colis pret
    |
    +--> [Livraison] -------> Expedition / livraison
    |
    +--> [Notifications] ---> Email, SMS, suivi
    |
    +--> [Support] ---------> Annulation, remboursement, litige

Observabilité et opérations

En architecture distribuée, l'observabilité n'est pas un luxe ; c'est une condition de survie. Quand un parcours traverse plusieurs services, il ne suffit plus de lire un log applicatif central. Il faut pouvoir reconstruire une requête, comprendre son contexte, mesurer ses latences et relier les symptômes aux dépendances.

• Logs structurés : événements compréhensibles, horodatés, corrélables et filtrables.
• Métriques : taux de succès, latence, saturation, erreurs, files, dépendances aval.
• Traces : chemin d’une requête ou d’un workflow entre services.
• Dashboards : vues opérationnelles centrées sur les parcours, pas seulement sur les machines.
• Alerting : signaux reliés à un impact utilisateur, avec bruit limité.
• SLO : objectif de niveau de service qui traduit la fiabilité attendue en termes mesurables.
• Ownership opérationnel : l'équipe qui possède le service doit comprendre ses symptômes, ses dépendances et ses modes de panne.

AWS Builders' Library insiste sur l'instrumentation pour obtenir une visibilité opérationnelle dans les systèmes distribués. Le point n'est pas d'empiler des outils, mais de rendre le système observable par construction : corrélation des requêtes, dimensions utiles, métriques de dépendances et diagnostic des pannes partielles. [S5]

Résilience

Un système distribué ne tombe pas toujours entièrement. Il se dégrade par morceaux. Un service aval ralentit, une file se remplit, un retry amplifie la charge, un timeout est trop long, une opération est exécutée deux fois. La résilience consiste à concevoir pour ces pannes partielles au lieu de supposer qu'elles seront rares.

• Timeouts : définir combien de temps un appel peut bloquer avant d'être considéré comme échoué.
• Retries : réessayer uniquement quand l'opération est sûre, bornée et accompagnée de backoff.
• Backoff et jitter : éviter que tous les clients réessayent au même moment et aggravent la surcharge. [S3]
• Idempotence : permettre à une demande répétée de produire le même effet logique, indispensable pour les retries sûrs. [S4]
• Graceful degradation : continuer à servir une partie de l'expérience quand une dépendance non critique échoue.
• Blast radius : limiter l'étendue d'un incident pour qu'un problème local ne devienne pas une panne globale.
• Files d'attente et dead-letter queues : absorber temporairement une pression et isoler les messages qui ne peuvent pas être traités correctement.

Ces mécanismes ont un coût. Ils demandent des choix explicites : que peut-on réessayer ? Combien de temps ? Avec quelle clé d'idempotence ? Quel événement doit être envoyé en cas d'échec ? Quel backlog est acceptable ? Les sources AWS modernes donnent un vocabulaire opérationnel précis pour traiter ces questions. [S3][S4][S6]

Impact organisationnel

L'architecture évolue avec l'organisation. Une architecture orientée services n'a de sens que si les frontières techniques correspondent à des frontières de responsabilité. Sinon, on obtient simplement un monolithe distribué : plusieurs services, mais toujours les mêmes dépendances, validations transverses et files d'attente humaines.

La loi de Conway rappelle que les systèmes reflètent les structures de communication des organisations qui les construisent. Dans le contexte Amazon, les sources publiques parlent d'équipes responsables de services et d'une culture opérationnelle où les équipes ne se contentent pas de livrer du code ; elles doivent aussi comprendre son comportement en production. [S14][S15]

La formule “you build it, you run it” doit être utilisée prudemment : elle résume une culture d'ownership souvent associée à Amazon, mais elle ne doit pas servir à imaginer une structure d'équipe précise non documentée. La leçon généralisable est plus sobre : l'autonomie technique doit être accompagnée d'une responsabilité opérationnelle et de standards partagés. [S16]

• Des plateformes internes réduisent le coût de création, déploiement et observation des services.
• Des standards communs évitent que chaque équipe réinvente auth, logging, CI/CD, alerting et sécurité.
• Des contrats explicites rendent les dépendances visibles et négociables.
• Des équipes propriétaires réduisent le flou sur les décisions de modèle, de roadmap et d’exploitation.

Stack technique : ce qui est intéressant sans inventer

Il serait tentant d'ajouter une liste “Java, Oracle, Kubernetes, Kafka, containers” pour rendre l'étude plus moderne. Ce serait trompeur si la source ne le dit pas. La partie la plus utile pour des ingénieurs n'est donc pas un faux inventaire, mais une distinction entre stack documenté, stack déductible et stack inconnu.

La conclusion technique est plus forte qu'une liste de technologies : Amazon a d'abord dû déplacer le contrat architectural. Tant que le contrat public d'un domaine était une table partagée, changer de langage, de framework ou d'orchestrateur n'aurait pas supprimé le couplage fondamental.

Les informations modernes sur les bases sont néanmoins utiles : AWS indique qu'Amazon Consumer a migré 75 PB de données stockées dans près de 7 500 bases Oracle vers DynamoDB, Aurora, Amazon RDS et Redshift. Une autre publication AWS indique qu'Amazon.com utilise AWS DMS, Aurora et DynamoDB, notamment pour de très gros volumes de mises à jour catalogue. Ces détails montrent une trajectoire moderne vers des services de données spécialisés, mais ils ne documentent pas le stack complet de la période Obidos. [S17][S18]

Ce qu’Amazon nous apprend sur le passage aux microservices

• Les microservices ne sont pas le point de départ naturel de chaque produit.
• La donnée partagée est souvent le vrai problème, plus que la taille du code.
• Le couplage doit être compris et réduit avant d’être distribué.
• Les interfaces sont plus importantes que les frameworks.
• L’organisation doit évoluer avec l’architecture, sinon les services reproduisent le chaos existant.
• La complexité distribuée doit être payée seulement quand la douleur est durable, mesurable et liée à des frontières métier claires.
• Les plateformes internes et l’observabilité ne sont pas des extras ; elles font partie du coût réel de l’architecture.

Martin Fowler défend une idée compatible avec cette lecture : commencer par un monolithe peut être rationnel tant que les frontières du domaine ne sont pas encore stables. L'extraction progressive, y compris par un modèle type Strangler Fig, est souvent plus réaliste qu'un basculement massif. [S12][S13]

Ce qu'il ne faut pas conclure

Cette section est volontairement explicite, parce que les mauvaises leçons tirées d'Amazon sont fréquentes.

• Amazon ne prouve pas que chaque startup doit commencer en microservices.
• Amazon ne prouve pas que le monolithe est mauvais.
• Amazon ne prouve pas qu'il faut tout découper.
• Amazon ne prouve pas qu'une base par service suffit à créer une bonne architecture.
• Amazon montre qu'à une certaine échelle, le couplage centralisé limite l'innovation, la fiabilité et l'autonomie.
• La bonne leçon est progressive, pas dogmatique : comprendre le couplage, clarifier les domaines, créer des interfaces, puis extraire là où la valeur justifie le coût.

Framework de décision moderne

Même si Amazon n'est pas exactement un cas “monolithe modulaire vers microservices”, son histoire aide à construire une matrice de décision moderne. La question n'est pas de suivre une mode, mais de choisir la forme qui minimise le coût total de changement.

Quand rester en monolithe
--------------------------
- Petite equipe
- Domaine instable
- Faible trafic ou scaling simple
- Besoin de rapidite produit
- Peu d'exigences de deploiement independant
- Modele de donnees encore en exploration

Quand passer au monolithe modulaire
-----------------------------------
- Couplage croissant
- Modules metier visibles
- Tests lents ou fragiles
- Ownership flou
- Changements locaux qui cassent trop de zones
- Besoin de frontieres internes sans payer tout le cout distribue

Quand extraire en services
--------------------------
- Domaine stable
- Ownership clair
- Scaling independant
- Deploiement independant utile
- Contraintes de fiabilite differentes
- Donnees isolables
- Douleur mesurable et durable

Le monolithe modulaire est souvent l'étape oubliée. Il ne contredit pas les microservices ; il prépare la séparation en rendant les frontières visibles avant de les transformer en appels réseau.

Playbook inspiré d'Amazon pour une entreprise moderne

1. Cartographier les domaines métier : catalogue, commande, paiement, client, support, facturation, logistique ou équivalents.
2. Identifier les bases et tables partagées critiques : qui lit, qui écrit, qui dépend du schéma ?
3. Mesurer le couplage : changements transverses, incidents liés au schéma, tests cassés, coordination nécessaire.
4. Créer des interfaces internes : APIs, événements ou façades qui masquent les détails de stockage.
5. Interdire progressivement l'accès direct aux données d'un autre domaine, en commençant par les nouvelles fonctionnalités.
6. Définir un ownership par domaine : responsable du contrat, du modèle, de la roadmap et du comportement en production.
7. Extraire d'abord les domaines stables : éviter de distribuer une zone encore en forte découverte.
8. Introduire l'observabilité avant la distribution massive : logs, métriques, traces, dashboards et alertes utiles.
9. Automatiser CI/CD : un service indépendant sans pipeline fiable devient une charge manuelle.
10. Définir SLOs et responsabilités opérationnelles : chaque service doit avoir une définition de santé compréhensible.
11. Répéter uniquement quand la valeur est claire : chaque extraction doit réduire un coût réel ou ouvrir une autonomie utile.

Architecture illustrative moderne

A. Architecture centralisée initiale

[Clients web]
     |
     v
[Application centrale]
     |
     v
[Bases partagees]
     |
     +-- Produits
     +-- Categories
     +-- Clients
     +-- Pays
     +-- Commandes

B. Architecture orientée services

[Clients]
    |
    v
[Presentation / Web]
    |
    +--> [Service Catalogue] --> [Donnees Catalogue]
    +--> [Service Client] ----> [Donnees Client]
    +--> [Service Commande] --> [Donnees Commande]
    +--> [Service Paiement] --> [Donnees Paiement]

C. Architecture hybride moderne

[Monolithe modulaire]
    |
    +-- Module Admin
    +-- Module Backoffice
    |
    +--> [Service Paiement]
    +--> [Service Notification]
    +--> [Service Search]
    +--> [Service Catalogue]
              |
              v
        [Evenements domaine]

D. Service propriétaire de ses données

[Consommateur]
     |
     v
[API / Evenement du service]
     |
     v
[Service proprietaire]
     |
     v
[Modele interne + stockage]

Regle : le stockage interne n'est pas l'API publique du domaine.

E. Workflow commande événementiel

CommandeCreee
    |
    +--> PaiementAutorise
    |       |
    |       +--> PreparationDemandee
    |
    +--> ClientNotifie
    |
    +--> FacturePreparee
    |
    +--> LivraisonPlanifiee
            |
            +--> CommandeLivree

Tableau Avant / Après

Erreurs fréquentes en s'inspirant mal d'Amazon

• Copier Amazon sans avoir l'échelle, les contraintes ou la maturité opérationnelle d'Amazon.
• Commencer par des microservices alors que le domaine est encore instable.
• Distribuer un mauvais design au lieu de réduire le couplage.
• Garder une base partagée entre microservices et croire que le système est découplé.
• Oublier l'observabilité, puis découvrir trop tard que les incidents sont impossibles à diagnostiquer.
• Créer des services CRUD sans domaine métier réel.
• Ignorer l'organisation : des services sans owners clairs deviennent des dépendances orphelines.
• Confondre SOA, microservices et simple découpage technique par couche.
• Extraire tout ce qui bouge, au lieu de commencer par les domaines stables et douloureux.

Conclusion

Le monolithe n'était pas l'ennemi. Le vrai problème était le couplage qui empêchait Amazon d'évoluer à la vitesse de son ambition.

Amazon montre que l'architecture est une réponse à un contexte. Au départ, centraliser peut accélérer. Ensuite, lorsque le domaine, les données et l'organisation grandissent, le même modèle peut freiner. La solution n'est pas de copier une forme finale, mais de comprendre la pression qui a rendu cette forme nécessaire.

Les microservices ne sont pas une architecture de départ ; ils sont une réponse à une douleur d'échelle, de couplage et d'organisation.

À retenir

• Un monolithe peut être le meilleur choix initial.
• Le vrai signal de danger est le couplage durable, surtout autour des données.
• Une base partagée devient vite une API implicite et fragile.
• Les services doivent exposer des contrats, pas leurs tables internes.
• La distribution ajoute latence, pannes partielles, retries, timeouts et observabilité obligatoire.
• Les frontières techniques doivent suivre des frontières métier et organisationnelles.
• Un service sans ownership opérationnel clair est une dette.
• Le monolithe modulaire est souvent une étape saine avant l’extraction.
• Copier Amazon sans ses contraintes mène souvent à un monolithe distribué.
• La bonne stratégie est progressive : mesurer, découpler, observer, extraire, répéter.

Sources et niveau de preuve

Les sources [S1] et [S2] sont les sources principales pour les affirmations historiques spécifiques à Amazon. Les sources AWS Builders' Library et AWS Well-Architected sont utilisées pour relier cette histoire aux pratiques modernes des systèmes distribués. Les sources Fowler servent de cadre externe reconnu pour éviter une conclusion dogmatique sur les microservices.

Les détails non vérifiables publiquement, comme des métriques internes, des dates exactes de migration service par service ou une cartographie complète des équipes Amazon retail, ne sont pas affirmés dans cette étude.