Migrer vers les microservices est une conversation. Concevoir une architecture microservices qui ne s'effondre pas en monolithe distribué en est une autre. Voici les principes qui séparent les deux,que vous migriez ou que vous construisiez en partant de zéro.

Les frontières de service suivent les capacités métier, pas les couches techniques

L'erreur la plus courante est de découper les services par couche technique,un "service models", un "service controllers". Les frontières devraient suivre les capacités métier et les bounded contexts : un service Orders, un service Shipping, un service Billing, chacun possédant une tranche verticale complète de son domaine.

Chaque service possède ses données,sans exception

Une base de données partagée entre services est le moyen le plus rapide de finir avec un monolithe distribué : tout changement de schéma nécessite désormais de coordonner les déploiements entre équipes, et les "services indépendants" ne le sont que de nom.

// Anti-pattern : le service Shipping interroge directement la base Orders
$order = DB::connection('orders_db')->table('orders')->find($orderId);

// Pattern : le service Shipping interroge le service Orders via son API
$order = Http::get(config('services.orders.url') . "/orders/{$orderId}")->json();

Patterns de communication : choisir délibérément

• ✓REST ou gRPC synchrone pour les requêtes nécessitant une réponse immédiate,authentification, autorisation de paiement.
• ✓Messagerie asynchrone (événements, queues) pour tout ce qui peut arriver plus tard,notifications, analytics, logs d'audit.
• ✓Éviter les chaînes synchrones bavardes où le service A attend B qui attend C,latence et modes de panne s'accumulent à chaque saut.

Concevoir pour l'échec : rien n'est optionnel ici

• ✓Timeouts et circuit breakers sur chaque appel réseau,une dépendance lente ne doit pas provoquer une panne totale en cascade.
• ✓Retries avec backoff exponentiel, associés à des clés d'idempotence pour que les écritures retentées ne dupliquent pas les données.
• ✓Dégradation gracieuse : définir ce que fait le service quand une dépendance est en panne, plutôt que de le découvrir en production.

L'observabilité n'est pas optionnelle non plus

Une seule requête utilisateur peut toucher six services. Sans tracing distribué (OpenTelemetry), sans IDs de corrélation propagés à chaque appel, et sans logging centralisé, déboguer cette requête est de la devinette déguisée en rapport d'incident.

Les microservices échangent de la simplicité contre de la scalabilité et de l'autonomie d'équipe. Ce compromis vaut le coup une fois que l'équipe ou le domaine a dépassé une seule unité déployable,pas par défaut, et pas parce que le terme est à la mode.