building microservices

The problem

Building microservices often leads to "distributed monoliths" where services are tightly coupled and cannot be deployed independently. Developers struggle with managing distributed transactions, choosing between sync and async communication, and defining service boundaries that don't break with every change.

What it does

• Identifies service boundaries using Domain-Driven Design (DDD) and bounded contexts to ensure high cohesion.
• Evaluates communication patterns including REST, gRPC, and event-driven messaging based on specific latency and coupling trade-offs.
• Designs distributed workflows using the Saga pattern to replace problematic two-phase commits.
• Audits architecture against the "independent deployability" rule to prevent shared-database anti-patterns.
• Provides strategy for migration from monoliths, including repo management and CI/CD pipeline structures.

Frameworks & tools

Kubernetes, Docker, REST, gRPC, Message Brokers, CI/CD pipelines, and Infrastructure as Code (IaC).

Why this beats prompting it yourself

General LLMs often suggest "industry best practices" that lead to tight coupling, like sharing databases. This skill enforces the strict architectural constraints and decision frameworks from Sam Newman's definitive guide, ensuring you don't build a system that is impossible to maintain.

Use cases

• Deciding whether to split a specific module out of a monolith.
• Designing a backward-compatible API versioning strategy for multiple consumers.
• Choosing between orchestration and choreography for a complex business process.
• Setting up a deployment strategy using canary releases or feature toggles.

Known limitations

Does not provide low-level language-specific code implementation. Focuses on architectural design and organizational patterns rather than syntax.