원클릭으로 Manus에서 모든 스킬 실행

darwin-microservice-patterns

스타7

포크1

업데이트2026년 2월 28일 18:24

Microservice technical patterns for infrastructure and API design. Use when planning service changes, reviewing API contracts, or evaluating deployment strategies.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

The-Darwin-Project

The-Darwin-Project/Blackboard

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Microservice Technical Patterns

Deployment & Independence

Independently deployable: Each service MUST deploy without coordinating with others. If a plan requires simultaneous deployment, redesign with backward-compatible contracts first.
Feature flags over deploy coordination: Use feature flags for progressive enablement rather than synchronized rollouts.

API & Data Contracts

Backward-compatible API changes: Always additive. New fields are optional. Old fields never removed in the same release.
API versioning: If breaking changes are unavoidable, version the API (/v1/, /v2/).
API contracts first: Specify the contract (REST endpoint, event schema) before implementation details.
Database schema independence: Each service owns its data store. No shared databases. Migrations must be backward-compatible.

Resilience

Circuit breakers: Any inter-service call should have timeout + retry + fallback. Flag plans missing resilience patterns.
Idempotency: Any state-modifying operation must be safe to retry. Specify how duplicate calls are handled.
Health endpoints: Every service must expose /health (liveness) and /ready (readiness) with meaningful checks.

Operational Hygiene

Observability: Plans must include how changes will be monitored (metrics, logs, alerts).
Configuration via environment: No hardcoded URLs, credentials, or feature flags in code. Everything via env vars or ConfigMaps.
Stateless services: Flag any in-process state that breaks horizontal scaling (caches without TTL, sessions, in-memory queues). Externalize to Redis/DB.

이 저장소의 다른 Skills

같은 저장소

darwin-dockerfile-safety

The-Darwin-Project/Blackboard

Safety rules for modifying Dockerfiles and Containerfiles. Use when editing container build files.

2026-07-217

darwin-reporting-context

The-Darwin-Project/Blackboard

MR/PR context gathering and diagnostic reporting guidelines. Activates when working on events that reference MRs/PRs or when reporting investigation findings.

2026-07-217

darwin-team-huddle

The-Darwin-Project/Blackboard

Team coordination for implement and test modes. Developer and QE use team_send_results for final reports, team_huddle for mid-task questions to FRIDAY.

2026-07-217

darwin-gitops

The-Darwin-Project/Blackboard

GitOps workflow rules for modifying infrastructure via git. Use when cloning repos, modifying Helm values, committing, pushing, or verifying deployments.

2026-07-137

darwin-mr-lifecycle

The-Darwin-Project/Blackboard

MR/PR lifecycle operations -- pipeline check, retest, merge, conflict reporting. Extends darwin-gitlab-ops.

2026-07-137

darwin-comms

The-Darwin-Project/Blackboard

Report findings and status updates to the Darwin FRIDAY. Use team_send_results for final reports (task modes). In message mode, use team_send_message instead.

2026-07-097

name	darwin-microservice-patterns
description	Microservice technical patterns for infrastructure and API design. Use when planning service changes, reviewing API contracts, or evaluating deployment strategies.
roles	["architect"]
modes	["plan"]

Microservice Technical Patterns

Deployment & Independence

Independently deployable: Each service MUST deploy without coordinating with others. If a plan requires simultaneous deployment, redesign with backward-compatible contracts first.
Feature flags over deploy coordination: Use feature flags for progressive enablement rather than synchronized rollouts.

API & Data Contracts

Backward-compatible API changes: Always additive. New fields are optional. Old fields never removed in the same release.
API versioning: If breaking changes are unavoidable, version the API (/v1/, /v2/).
API contracts first: Specify the contract (REST endpoint, event schema) before implementation details.
Database schema independence: Each service owns its data store. No shared databases. Migrations must be backward-compatible.

Resilience

Circuit breakers: Any inter-service call should have timeout + retry + fallback. Flag plans missing resilience patterns.
Idempotency: Any state-modifying operation must be safe to retry. Specify how duplicate calls are handled.
Health endpoints: Every service must expose /health (liveness) and /ready (readiness) with meaningful checks.

Operational Hygiene

Observability: Plans must include how changes will be monitored (metrics, logs, alerts).
Configuration via environment: No hardcoded URLs, credentials, or feature flags in code. Everything via env vars or ConfigMaps.
Stateless services: Flag any in-process state that breaks horizontal scaling (caches without TTL, sessions, in-memory queues). Externalize to Redis/DB.