microservices-architect

Design microservices architectures and decompose monoliths into bounded-context services.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/kamelmh/opencode-config --skill microservices-architect-kamelmh
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: microservices-architect
Source: https://github.com/kamelmh/opencode-config/tree/main/skills/microservices-architect
Command: npx skills add https://github.com/kamelmh/opencode-config --skill microservices-architect-kamelmh

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps you turn tangled systems into well-defined distributed architectures, reducing coupling, improving team autonomy, and making large-scale services easier to evolve safely.

Core Features & Use Cases

  • Service Boundary Design: Identifies bounded contexts and decomposes monoliths into independently deployable services.
  • Communication and Data Strategy: Recommends synchronous and asynchronous patterns, database-per-service ownership, event-driven workflows, CQRS, and saga-based coordination.
  • Reliability and Operations: Adds resilience patterns, observability, correlation IDs, health checks, readiness probes, and deployment guidance for production environments.
  • Use Case: If you are splitting an order platform into payment, inventory, shipping, and notification services, this Skill helps define boundaries, choose message flows, and plan failure handling end to end.

Quick Start

Ask the microservices-architect skill to decompose your current system into service boundaries, communication patterns, data ownership, and resilience practices for a production-ready architecture plan.

Frequently Asked Questions about microservices-architect

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decompose a monolith into bounded-context microservices?

Decomposing a monolith into bounded-context microservices requires identifying domain boundaries and splitting them into independently deployable services. This Skill designs service boundaries, defines database-per-service ownership, and establishes clear communication patterns for distributed system planning.

What is the saga pattern and when should I use it for microservices communication?

The saga pattern coordinates distributed transactions across microservices using event-driven workflows. Use saga orchestration when cross-aggregate messaging requires async communication to maintain data consistency without distributed locks, ensuring reliable end-to-end business processes.

How do I design resilience and observability for distributed systems?

Designing resilience and observability for distributed systems requires circuit breakers, correlation IDs, health probes, and distributed tracing. This Skill applies these patterns to cloud-native applications, adding readiness probes and versioned APIs for reliable production environments.

What's the best way to handle data ownership in a microservices architecture?

Handling data ownership in microservices architecture requires database-per-service ownership to reduce coupling. This Skill recommends synchronous and asynchronous patterns, event-driven workflows, and CQRS to manage data boundaries while maintaining team autonomy for independently deployable services.

Can I use this approach to split an order platform into payment, inventory, and shipping services?

Yes, you can split an order platform into payment, inventory, shipping, and notification services. This Skill helps define service boundaries, choose message flows, and plan failure handling end to end, creating a production-ready architecture plan for bounded-context decomposition.

When should I not use microservices architecture for my application?

You should not use microservices architecture when your system lacks clear bounded contexts or cannot support distributed tracing, health probes, and circuit breakers. This approach requires database-per-service ownership and async cross-aggregate messaging, adding operational complexity unsuitable for simpler domains.