/system-design-principles

name: system-design-principles
description: "Define module boundaries, dependency direction, data ownership, resilience, and distributed-system trade-offs. Use for architecture, service boundaries, coupling, scalability, or failure-cascade decisions; defer session facilitation to system-design-methodology."
metadata:
  triggers:
    keywords:
      - architecture
      - scalability
      - microservice
      - microservices
      - module boundary
      - coupling
      - bounded context
      - dependency direction
      - clean architecture
      - cap theorem
      - idempotency

System Design Principles

**Priority: P0 (CRITICAL)**

Workflow: Evaluate Architecture for New Feature

1. Identify bounded contexts and module boundaries 2. Name the data owner and define dependency direction (outer layers depend on inner) 3. Select communication pattern (sync REST, async event, or hybrid) and failure behavior 4. Validate CAP trade-offs only for distributed components 5. Record boundary, trade-off, and rollback in an ADR

For a failing synchronous dependency, keep the critical path explicit: timeout and circuit-break the dependency, return a defined degraded/fallback result where safe, and move non-critical notifications to an asynchronous event.

Architectural Principles

• **SoC**: Divide into distinct sections per concern.
• **SSOT**: One source, reference elsewhere.
• **Fail Fast**: Fail visibly when errors occur.
• **Graceful Degradation**: Core functional even if secondary fails.

Modularity & Coupling

• **High Cohesion**: Related functionality in one module.
• **Loose Coupling**: Use interfaces for communication.
• **DI**: Inject dependencies, don't hardcode.

See [implementation examples](references/implementation.md) for dependency flow diagrams.

Common Patterns

• **Layered**: Presentation -> Logic -> Data.
• **Event-Driven**: Async communication between decoupled components.
• **Clean/Hexagonal**: Core logic independent of frameworks.
• **Statelessness**: Favor stateless for scaling/testing.
• **Monolith first**: Start modular-monolith; split a service out only when a module needs independent scaling, release cadence, or ownership.

Distributed Systems

• **CAP**: Apply only to behavior during a network partition in a distributed data system. See [CAP & Consistency Patterns](references/distributed-systems.md); consistency, availability, and partition tolerance are not product labels or uptime percentages.
• **Idempotency**: Preserve one intended effect for retries of the same business operation. Use the [idempotency contract](references/idempotency-contract.md), not “without side effects” or a fresh key per transport attempt.
• **Circuit Breaker**: Fail fast on failing services. See [Resilience Patterns](references/resilience-patterns.md).
• **Eventual Consistency**: State a freshness/convergence objective, how it is measured, and behavior when it is missed; do not promise a generic convergence time.

Documentation & Evolution

• **Design Docs**: Write specs before major implementations.
• **Versioning**: Version APIs/schemas for backward compatibility.
• **Extensibility**: Introduce Strategy/Factory or similar abstraction only when concrete variation, multi-tenant divergence, or an explicit plugin boundary exists. Hypothetical future extension alone does not justify abstraction layers.

References

• [Distributed Systems & CAP Theorem](references/distributed-systems.md)
• [Resilience Patterns (Circuit Breaker, Bulkhead, Retry)](references/resilience-patterns.md)

Anti-Patterns

• **No god classes**: Single Responsibility — one reason to change per module.
• **No blanket synchronous-coupling ban**: choose synchronous, asynchronous, or hybrid communication from the boundary's consistency, latency, failure, and coupling requirements. A bounded synchronous transaction can protect an immediate invariant; independent notifications may remain asynchronous. State the trade-offs and failure behavior.
• **No premature abstraction**: Design for current requirements and proven load; introduce abstraction patterns (e.g. Strategy/Factory) when concrete variation, multi-vendor/tenant divergence, or an explicit plugin/change boundary exists, rather than for speculative future extension. Conversely, do not ban valid abstractions when concrete variation justifies them.