Stats
Actions
Tags
From system-design
Evaluate whether to keep, refactor, or break apart a monolithic system. Use when facing scaling or team velocity challenges with monoliths.
How this skill is triggered — by the user, by Claude, or both
Slash command
/system-design:monolith-assessmentThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Systematically evaluate a monolithic system to determine the right evolution path: stay monolith, strangler fig, distributed monolith, or true microservices.
Systematically evaluate a monolithic system to determine the right evolution path: stay monolith, strangler fig, distributed monolith, or true microservices.
You are analyzing a monolithic system. The user is experiencing pain (scaling, slow deployment, team conflicts) and needs objective guidance on whether to split services or optimize the monolith. Read code samples, deployment info, and team structure.
Based on Sam Newman, Martin Fowler, and Shopify's monolith journey:
Score Pain Dimensions: Rate the monolith on (1-5): deployment frequency, team wait times, scaling per component, technology brittleness. High scores indicate split pressure.
Map Team Structure: How many teams? Do they work independently? Are code conflicts blocking? If >3 teams, monolith is likely bottleneck.
Identify Seams: Find natural split points (feature flags, database views isolating concerns, API boundaries). Ask: "Could I change this without touching that?"
Cost-Benefit Analysis: For each proposed split, calculate: split cost (effort + infrastructure), benefit (deployment frequency +X%, scaling independently, team autonomy). Use threshold: benefit > 3x cost.
Choose Evolution Path:
npx claudepluginhub sethdford/claude-skills --plugin architect-system-designDecomposes monoliths or designs new microservices systems using DDD bounded contexts and proven patterns from Netflix/Amazon. Guides service decomposition, contracts, data strategy, and observability.
Designs microservices decomposition using DDD: bounded contexts, service boundaries, communication patterns, data ownership, and migration roadmap. For monolith decomposition or greenfield service design.
Designs modular monolith boundaries, module layout, dependency rules, shared/platform seams, and extraction triggers for systems not yet split into microservices.