microservices-architecture
Design and implement microservices architecture including service boundaries, communication patterns, API gateways, service mesh, service discovery, and distributed system patterns. Use when building microservices, distributed systems, or service-oriented architectures.
By aj-geddes · 507 installs
npx skills add aj-geddes/useful-ai-prompts --skill microservices-architecture
Source repository · Upstream listing
Microservices Architecture
Table of Contents
[Overview]( overview)
[When to Use]( when to use)
[Quick Start]( quick start)
[Reference Guides]( reference guides)
[Best Practices]( best practices)
Overview
Comprehensive guide to designing, implementing, and maintaining microservices architectures. Covers service decomposition, communication patterns, data management, deployment strategies, and observability for distributed systems.
When to Use
Designing new microservices architectures
Decomposing monolithic applications
Implementing service to service communication
Setting up API gateways and service mesh
Implementing service discovery
Managing distributed transactions
Designing inter service data consistency
Scaling independent services
Quick Start
Minimal working example:
Reference Guides
Detailed implementations in the references/ directory:
Guide Contents
[Service Boundary Design](references/service boundary design.md) Service Boundary Design
[Communication Patterns](references/communication patterns.md) Communication Patterns
[API Gateway Pattern](references/api gateway pattern.md) API Gateway Pattern
[Service Discovery](references/service discovery.md) Service Discovery
[Data Consistency Patterns](references/data consistency patterns.md) Data Consistency Patterns
[Service Mesh (Istio)](references/service mesh istio.md) Service Mesh (Istio)
Best Practices
✅ DO
Design services around business capabilities
Use asynchronous communication where possible
Implement circuit breakers for resilience
Use API gateway for cross cutting concerns
Implement distributed tracing
Use service mesh for service to service communication
Design for failure (chaos engineering)
Implement health checks for all services
Use correlation IDs for request tracking
Version your APIs
Implement proper monitoring and alerting
Use event driven architecture for loose coupling
Implement idempotent operations
Use database per service pattern
❌ DON'T
Share databases between services
Create overly granular services (nanoservices)
Use distributed transactions (two phase commit)
Ignore network latency and failures
Share domain models between services
Deploy all services as one unit
Hardcode service URLs
Forget to implement authentication/authorization
Use synchronous calls for long running operations
Ignore backward compatibility
Skip monitoring and logging
Create circular dependencies between services