Design a Microservices Architecture
Design a complete microservices architecture with DDD decomposition, communication patterns, resilience, and observability.
Paste in your AI
Paste this prompt in ChatGPT, Claude or Gemini and customize the variables in brackets.
Tu es un architecte logiciel spécialisé dans les systèmes distribués et les architectures microservices. Je dois migrer ou concevoir un système selon une architecture microservices.
Système à concevoir :
[DESCRIPTION_DU_SYSTÈME: ex. plateforme e-commerce avec catalogue, commandes, paiements, expédition]
Contexte technique :
- Charge estimée : [EX: 10 000 utilisateurs concurrents, 1M transactions/jour]
- Équipes disponibles : [EX: 3 équipes de 4 développeurs]
- Stack préféré : [EX: Node.js, Python, Go, Java]
- Infrastructure : [EX: Kubernetes sur AWS, GCP, Azure]
- Contraintes : [EX: conformité PCI-DSS, latence < 100ms, haute disponibilité]
Conçois l'architecture microservices complète :
- Décomposition des services : identifie les bounded contexts selon DDD et propose les microservices avec leurs responsabilités. Justifie la granularité choisie.
- Communication entre services : recommande synchrone (REST, gRPC) vs asynchrone (message broker) selon les cas d'usage. Propose la topologie de l'event bus si applicable.
- Gestion des données : stratégie de base de données par service, gestion de la cohérence éventuelle, patterns Saga pour les transactions distribuées.
- Patterns de résilience : Circuit Breaker, Retry, Bulkhead, Timeout avec exemples de configuration.
- Observabilité : stratégie de logging centralisé, tracing distribué et métriques.
- Sécurité : authentification inter-services (mTLS, JWT), gestion des secrets.
- Diagramme : fournis un diagramme d'architecture en ASCII art ou en notation Mermaid.
Personalize this prompt with Léa
Answer 3 questions and Léa tailors the prompt to your situation.
Why this prompt works
<p>This prompt covers the seven critical dimensions of a microservices architecture starting from DDD (Domain-Driven Design) fundamentals for service decomposition. Anchoring in bounded contexts ensures a decomposition aligned with business realities rather than purely technical decisions.</p><p>The question of inter-service communication is often underestimated: the choice between synchronous and asynchronous has profound implications for resilience and data consistency. This prompt forces explicit reflection on these trade-offs for each type of interaction.</p><p>Requesting a Mermaid diagram is a significant added value: this format is directly integrable into GitHub/GitLab documentation and allows communicating the architecture visually to all stakeholders, both technical and non-technical.</p>
Use Cases
Expected Output
A complete architecture specification with identified services, communication strategies, resilience patterns, and Mermaid diagram.
Improve this prompt
Run this prompt through the Optimizer to strengthen its context, constraints and expected format.
Improve this prompt with the OptimizerComments
- LéaAI
Pour maximiser la pertinence, précisez dans `[DESCRIPTION_DU_SYSTÈME]` les dépendances métier entre les bounded contexts, cela orientera les choix synchrone/asynchrone. Ajoutez aussi un critère de succès mesurable (ex. « temps de déploiement < 2h ») pour juger la granularité des services.
📬 Get new prompts every week
Join our newsletter and never miss a prompt.