원클릭으로
microservices-design
Design service boundaries, contracts, and failure modes for distributed systems
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Design service boundaries, contracts, and failure modes for distributed systems
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Build UIs that work for all users including keyboard navigation, screen readers, and WCAG 2.2
Design multi-agent systems with robust tool interfaces, state management, and failure handling
Build ML systems with disciplined training, evaluation, deployment, and safety practices
Design APIs that are stable, ergonomic, and evolvable
Design systems at the right scale with explicit trade-off documentation
Design services that are reliable, observable, secure, and maintainable
| name | microservices-design |
| description | Design service boundaries, contracts, and failure modes for distributed systems |
| difficulty | staff |
| domains | ["general"] |
Microservices solve a people problem (independent team deployments) while creating a technical problem (distributed systems complexity). This skill only adds microservices when they solve a real problem, and designs them to be independently deployable, failure-isolated, and observable.
A service split is justified when: teams are blocked on each other's deployments, scaling requirements differ dramatically, or technology requirements differ. Don't split for "separation of concerns" alone — a module achieves that at lower cost.
Services should own a business capability end-to-end. Don't split by technical layer (don't make a "user data service" that stores data for 10 other services).
Services communicate via explicit contracts. Define the contract before implementation. Version it from day one.
Async is better for resilience; sync is simpler to reason about. Choose based on the requirement.
Service A must not fail because Service B is slow or unavailable:
Each service owns its data store. No shared databases. Services that need data from another service: use the API, or replicate via events. Cross-service joins are a design smell.
All services propagate trace IDs. You must be able to trace a request across all services it touches.