Agent Skills: System Architecture Skill

Master architectural design with SOLID principles, design patterns, microservices, and event-driven systems. Learn to design scalable backend systems.

solid-principlesdesign-patternsmicroservicesevent-drivenscalability
architectureID: pluginagentmarketplace/custom-plugin-backend/architecture

Skill Files

Browse the full folder contents for architecture.

Download Skill

Loading file tree…

skills/architecture/SKILL.md

Skill Metadata

Name
architecture
Description
Master architectural design with SOLID principles, design patterns, microservices, and event-driven systems. Learn to design scalable backend systems.

System Architecture Skill

Bonded to: architecture-patterns-agent


Quick Start

# Invoke architecture skill
"Help me decompose this monolith into microservices"
"Which design pattern should I use for notifications?"
"Design an event-driven architecture for order processing"

Instructions

  1. Analyze Requirements: Understand system needs and constraints
  2. Apply SOLID: Use SOLID principles for clean design
  3. Select Patterns: Choose appropriate design patterns
  4. Design Architecture: Select monolithic or distributed approach
  5. Validate Design: Review for scalability and maintainability

Architecture Selection Matrix

| Style | Best For | Team Size | Complexity | Scale | |-------|----------|-----------|------------|-------| | Monolith | MVPs, small teams | 1-10 | Low | Vertical | | Modular Monolith | Growing apps | 5-20 | Medium | Vertical | | Microservices | Large teams | 20+ | High | Horizontal | | Serverless | Variable load | 1-15 | Medium | Auto | | Event-Driven | Real-time, async | 10+ | High | Horizontal |


Decision Tree

Team size & complexity?
    │
    ├─→ Small team (1-5) → Monolith
    │
    ├─→ Growing team (5-20)
    │     ├─→ Clear domain boundaries → Modular Monolith
    │     └─→ Variable load → Serverless
    │
    └─→ Large team (20+)
          ├─→ Real-time/async heavy → Event-Driven
          └─→ Independent scaling needed → Microservices

SOLID Principles

| Principle | Description | Violation Sign | |-----------|-------------|----------------| | Single Responsibility | One reason to change | Class does too many things | | Open/Closed | Open for extension, closed for mod | Editing existing code for new features | | Liskov Substitution | Subtypes substitutable | Subclass changes behavior unexpectedly | | Interface Segregation | Small, specific interfaces | Clients implement unused methods | | Dependency Inversion | Depend on abstractions | High-level depends on low-level |


Design Patterns Quick Reference

Creational

| Pattern | Use Case | |---------|----------| | Singleton | Global config, connection pools | | Factory | Object creation with logic | | Builder | Complex object construction |

Structural

| Pattern | Use Case | |---------|----------| | Adapter | Interface compatibility | | Decorator | Dynamic behavior extension | | Facade | Simplified interface | | Proxy | Access control, caching |

Behavioral

| Pattern | Use Case | |---------|----------| | Observer | Event notifications | | Strategy | Algorithm selection | | Command | Action encapsulation | | State | State machines |


Examples

Example 1: Microservices Decomposition

E-commerce Monolith → Microservices

Services:
├── user-service        (auth, profiles)
├── product-service     (catalog, inventory)
├── order-service       (orders, checkout)
├── payment-service     (transactions)
├── notification-service (email, push)
└── api-gateway         (routing, auth)

Communication:
├── Sync: REST/gRPC for queries
└── Async: Event bus for commands/events

Example 2: Observer Pattern

from abc import ABC, abstractmethod
from typing import List

class Observer(ABC):
    @abstractmethod
    def update(self, event: dict) -> None:
        pass

class NotificationService:
    def __init__(self):
        self._observers: List[Observer] = []

    def subscribe(self, observer: Observer) -> None:
        self._observers.append(observer)

    def notify(self, event: dict) -> None:
        for observer in self._observers:
            observer.update(event)

class EmailHandler(Observer):
    def update(self, event: dict) -> None:
        send_email(event["user_id"], event["message"])

class PushHandler(Observer):
    def update(self, event: dict) -> None:
        send_push(event["user_id"], event["message"])

Example 3: Event-Driven Order Processing

# Saga pattern for order processing
class OrderSaga:
    async def process_order(self, order_id: str):
        try:
            # Step 1: Reserve inventory
            await self.inventory_service.reserve(order_id)

            # Step 2: Process payment
            await self.payment_service.charge(order_id)

            # Step 3: Confirm order
            await self.order_service.confirm(order_id)

        except PaymentError:
            # Compensating transaction
            await self.inventory_service.release(order_id)
            await self.order_service.cancel(order_id)
            raise

Troubleshooting

Anti-Pattern Detection

| Anti-Pattern | Sign | Solution | |--------------|------|----------| | Distributed Monolith | Services too coupled | Define bounded contexts | | God Class | One class does everything | Extract by responsibility | | Circular Dependencies | A→B→C→A | Introduce interfaces | | Shared Database | Multiple services, one DB | Database per service |

Debug Checklist

  1. Review dependency graph: Check for cycles
  2. Analyze coupling: Services should be loosely coupled
  3. Check cohesion: Related functionality together
  4. Validate boundaries: Clear service boundaries
  5. Test in isolation: Services deployable independently

Test Template

# tests/test_architecture.py
import pytest

class TestServiceBoundaries:
    def test_services_are_independent(self):
        # Each service should work independently
        user_service = UserService()
        order_service = OrderService()

        # Services communicate via events/APIs, not direct calls
        assert not hasattr(order_service, 'user_repository')

    def test_no_circular_dependencies(self):
        from app.services import dependency_graph
        cycles = dependency_graph.find_cycles()
        assert len(cycles) == 0

References

See references/ directory for:

  • ARCHITECTURE_GUIDE.md - Detailed patterns
  • design-patterns.yaml - Pattern catalog

Resources