engineering-arch-system-designer

Design system architectures, select patterns and databases, and document decisions as ADRs.

Updated Jan 28, 2026
One-click install
npx skills add https://github.com/scanady/nexus-skills --skill engineering-arch-system-designer-scanady
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: engineering-arch-system-designer
Source: https://github.com/scanady/nexus-skills/tree/main/skills/engineering-arch-system-designer
Command: npx skills add https://github.com/scanady/nexus-skills --skill engineering-arch-system-designer-scanady

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Designing a new system without clear requirements leads to over-engineered or fragile architectures. This Skill guides a structured architecture workflow: gathering functional and non-functional requirements, selecting the right architecture pattern, choosing data stores, planning for scale and failure, and documenting every significant decision as an Architecture Decision Record (ADR). ## Core Features & Use Cases - Requirements-Driven Design: Collects functional requirements, NFRs (performance, availability, security, cost), and constraints before any design work begins, using a structured NFR checklist. - Pattern & Database Selection: Matches requirements to architecture patterns (monolith, modular monolith, microservices, serverless, event-driven, CQRS) and database types (relational, document, key-value, time-series, graph, search) with explicit trade-off analysis. - ADR Documentation: Produces Architecture Decision Records for every significant choice, including alternatives considered and consequences. - Use Case: You are building an e-commerce platform and need to decide between a modular monolith and microservices, pick a primary database, and justify the choices to stakeholders. The Skill produces a full design document with component breakdown, scaling plan, failure modes, and ADRs. ## Quick Start Ask the agent to design the architecture for your system, for example: "Design the architecture for a multi-tenant SaaS billing platform expecting 10K concurrent users, and write ADRs for the database and messaging choices."

Frequently Asked Questions about engineering-arch-system-designer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I choose between a monolith and microservices architecture?▼

Choose a monolith for small teams (1-10 people) with simple domains and fast iteration needs. Choose microservices only when you have 20+ engineers, distinct domain boundaries, and genuinely different scaling requirements per service. A modular monolith is the intermediate step when a monolith grows messy but microservices overhead is not yet justified.

How do I write an Architecture Decision Record (ADR)?▼

An ADR documents one significant decision with five sections: Status, Context (forces and constraints), Decision (what you commit to), Consequences (positive, negative, neutral), and Alternatives Considered with rejection reasons. Store ADRs as numbered markdown files like docs/adr/0001-use-postgresql.md.

PostgreSQL vs MongoDB for a new application?▼

PostgreSQL fits when you need ACID transactions, complex joins, and structured schemas, and its JSONB support covers flexible attributes. MongoDB fits flexible nested schemas and rapid prototyping but is weaker for multi-document transactions and heavy relational queries.

What non-functional requirements should I gather before designing a system?▼

Gather targets for scalability (concurrent users, RPS, data volume), performance (p95 latency), availability (SLA percentage), reliability (RPO/RTO), security (auth model, compliance like GDPR or HIPAA), observability, deployment strategy, and infrastructure cost ceiling. Missing NFRs lead to wrong architecture choices.

When should I not use microservices or CQRS?▼

Avoid microservices when a single team deploys together and load profiles are uniform, since operational overhead (tracing, service discovery, gateways) outweighs benefits. Avoid CQRS for standard CRUD applications; it only pays off when reads far outnumber writes or read models need a different shape.