microservices

Name: microservices
Author: krzysztofsurdy

38installs1forks

How to install microservices?

krzysztofsurdy/code-virtuoso/microservices

$npx -y skills add krzysztofsurdy/code-virtuoso --skill microservices

Installs into the current project.

Summary

Microservices and distributed systems architecture patterns for scalable, resilient services. Use when the user asks to decompose a monolith, design service boundaries, implement saga orchestration, apply CQRS or event sourcing, configure circuit breakers, set up API gateways, ha

Files · 1

View on GitHub

SKILL.md

1	# Microservices and Distributed Systems
2
3	Microservices architecture splits a system into independently deployable services, each owning a specific business capability. This approach trades the simplicity of a monolith for flexibility in scaling, deployment, and technology choice - but only when the organizational and technical complexity is justified.
4
5	## When to Use Microservices vs Monolith
6
7	There is no universal answer. The decision depends on team size, domain complexity, and operational maturity.
8
9	\| Factor \| Monolith Favored \| Microservices Favored \|
10	\|---\|---\|---\|
11	\| Team size \| Small team (fewer than 10 developers) \| Multiple autonomous teams that need independent release cycles \|
12	\| Domain complexity \| Simple or poorly understood domain \| Well-understood domain with clear bounded contexts \|
13	\| Deployment cadence \| Infrequent releases are acceptable \| Different parts of the system need to ship at different speeds \|
14	\| Scaling needs \| Uniform load across the application \| Specific components need independent scaling \|
15	\| Operational maturity \| Limited infrastructure automation \| Mature CI/CD, monitoring, and container orchestration \|
16	\| Data isolation \| Shared database is manageable \| Services need independent data stores and schemas \|
17
18	Start monolithic unless you have a clear reason not to. A well-structured modular monolith can be decomposed later. A premature microservices architecture adds distributed systems complexity without proportional benefit.
19
20	---
21
22	## Service Decomposition Strategies
23
24	Deciding where to draw service boundaries is the hardest part. Get it wrong and you end up with a distributed monolith - all the costs of distribution with none of the benefits.
25
26	### By Business Capability
27
28	Align services to what the organization does rather than how the software is structured. Each service maps to a business function: order management, inventory, billing, notifications. Services change when the business capability they represent changes.
29
30	### By Subdomain (Domain-Driven Design)
31
32	Use bounded contexts from domain-driven design to identify natural boundaries. Each bounded context has its own ubiquitous language and internal model. A "Customer" in the billing context may carry different attributes than a "Customer" in the shipping context - and that is fine.
33
34	### Strangler Fig Migration
35
36	When migrating from a monolith, extract services incrementally rather than doing a big-bang rewrite. Route traffic through a facade that delegates to the monolith by default but redirects specific capabilities to new services as they are built. Over time, the monolith shrinks until it can be retired entirely. An anti-corruption layer translates between old and new models during the transition.
37
38	### Decomposition Heuristics
39
40	- High coupling between candidates - keep them together, they are likely one service
41	- Different rates of change - separate them, they will benefit from independent deployment
42	- Different scaling profiles - separate them, they need different resource allocation
43	- Shared data - if two candidates always read and write the same tables, splitting them creates unnecessary network chatter
44
45	---
46
47	## Communication Patterns
48
49	Services must communicate, and the choice between synchronous and asynchronous interaction shapes the entire system's behavior.
50
51	\| Style \| Mechanism \| Strengths \| Weaknesses \|
52	\|---\|---\|---\|---\|
53	\| Synchronous request-reply \| REST, gRPC, GraphQL \| Simple mental model, immediate response \| Temporal coupling, cascading failures \|
54	\| Asynchronous messaging \| Message queues (point-to-point) \| Decouples sender from receiver, buffering under load \| Added infrastructure, eventual consistency \|
55	\| Event-driven \| Event bus, pub/sub \| Loose coupling, multiple consumers possible \| Harder to debug, event ordering challenges \|
56
57	Rule of thumb: Use synchronous calls for queries that need an immediate answer. Use asynchronous messaging for commands and events where the sender does not need to wait for the result.
58
59	See [Communication Patterns Reference](references/communication-patterns.md) for detailed coverage of API gateways, service discovery, gRPC, service mesh, and sidecar patterns.
60
61	---
62
63	## Data Management in Distributed Systems
64
65	Each service should own its data. Shared databases create hidden coupling that defeats the purpose of service independence. This

People who liked this also viewed

6 picks

Type

microservices

38installs1forks

View on GitHub

How to install microservices?

krzysztofsurdy/code-virtuoso/microservices

$npx -y skills add krzysztofsurdy/code-virtuoso --skill microservices

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Microservices and Distributed Systems
2
3	Microservices architecture splits a system into independently deployable services, each owning a specific business capability. This approach trades the simplicity of a monolith for flexibility in scaling, deployment, and technology choice - but only when the organizational and technical complexity is justified.
4
5	## When to Use Microservices vs Monolith
6
7	There is no universal answer. The decision depends on team size, domain complexity, and operational maturity.
8
9	\| Factor \| Monolith Favored \| Microservices Favored \|
10	\|---\|---\|---\|
11	\| Team size \| Small team (fewer than 10 developers) \| Multiple autonomous teams that need independent release cycles \|
12	\| Domain complexity \| Simple or poorly understood domain \| Well-understood domain with clear bounded contexts \|
13	\| Deployment cadence \| Infrequent releases are acceptable \| Different parts of the system need to ship at different speeds \|
14	\| Scaling needs \| Uniform load across the application \| Specific components need independent scaling \|
15	\| Operational maturity \| Limited infrastructure automation \| Mature CI/CD, monitoring, and container orchestration \|
16	\| Data isolation \| Shared database is manageable \| Services need independent data stores and schemas \|
17
18	Start monolithic unless you have a clear reason not to. A well-structured modular monolith can be decomposed later. A premature microservices architecture adds distributed systems complexity without proportional benefit.
19
20	---
21
22	## Service Decomposition Strategies
23
24	Deciding where to draw service boundaries is the hardest part. Get it wrong and you end up with a distributed monolith - all the costs of distribution with none of the benefits.
25
26	### By Business Capability
27
28	Align services to what the organization does rather than how the software is structured. Each service maps to a business function: order management, inventory, billing, notifications. Services change when the business capability they represent changes.
29
30	### By Subdomain (Domain-Driven Design)
31
32	Use bounded contexts from domain-driven design to identify natural boundaries. Each bounded context has its own ubiquitous language and internal model. A "Customer" in the billing context may carry different attributes than a "Customer" in the shipping context - and that is fine.
33
34	### Strangler Fig Migration
35
36	When migrating from a monolith, extract services incrementally rather than doing a big-bang rewrite. Route traffic through a facade that delegates to the monolith by default but redirects specific capabilities to new services as they are built. Over time, the monolith shrinks until it can be retired entirely. An anti-corruption layer translates between old and new models during the transition.
37
38	### Decomposition Heuristics
39
40	- High coupling between candidates - keep them together, they are likely one service
41	- Different rates of change - separate them, they will benefit from independent deployment
42	- Different scaling profiles - separate them, they need different resource allocation
43	- Shared data - if two candidates always read and write the same tables, splitting them creates unnecessary network chatter
44
45	---
46
47	## Communication Patterns
48
49	Services must communicate, and the choice between synchronous and asynchronous interaction shapes the entire system's behavior.
50
51	\| Style \| Mechanism \| Strengths \| Weaknesses \|
52	\|---\|---\|---\|---\|
53	\| Synchronous request-reply \| REST, gRPC, GraphQL \| Simple mental model, immediate response \| Temporal coupling, cascading failures \|
54	\| Asynchronous messaging \| Message queues (point-to-point) \| Decouples sender from receiver, buffering under load \| Added infrastructure, eventual consistency \|
55	\| Event-driven \| Event bus, pub/sub \| Loose coupling, multiple consumers possible \| Harder to debug, event ordering challenges \|
56
57	Rule of thumb: Use synchronous calls for queries that need an immediate answer. Use asynchronous messaging for commands and events where the sender does not need to wait for the result.
58
59	See [Communication Patterns Reference](references/communication-patterns.md) for detailed coverage of API gateways, service discovery, gRPC, service mesh, and sidecar patterns.
60
61	---
62
63	## Data Management in Distributed Systems
64
65	Each service should own its data. Shared databases create hidden coupling that defeats the purpose of service independence. This

People who liked this also viewed

6 picks

Type