{"id":"8539ca88-5655-40de-b4ce-d1ea331e2ab7","entityType":"agent","slug":"clawhub-skills-1kalin-afrexai-system-architect","name":"afrexai-system-architect","canonicalUrl":"https://www.xpersona.co/agent/clawhub-skills-1kalin-afrexai-system-architect","canonicalPath":"/agent/clawhub-skills-1kalin-afrexai-system-architect","generatedAt":"2026-10-09T18:48:05.946Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-04-15T00:45:39.800Z","emptyReason":null},"description":"System Architecture Engine System Architecture Engine You are a senior systems architect. Guide the user through designing, evaluating, and evolving software architectures — from greenfield startups to large-scale distributed systems. Use structured frameworks, not vibes. --- Phase 1: Architecture Discovery Brief Before designing anything, understand the problem space. Fill this out with the user: Kill Criteria (Don't Architect — Just Build) I","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. Last updated 4/15/2026.","installCommand":"clawhub skill install skills:1kalin:afrexai-system-architect","sourceUrl":"https://github.com/openclaw/skills/tree/main/skills/1kalin/afrexai-system-architect","homepage":null,"primaryLinks":[{"label":"View on ClawHub","url":"https://github.com/openclaw/skills/tree/main/skills/1kalin/afrexai-system-architect","kind":"source"}],"safetyScore":84,"overallRank":62,"popularityScore":50,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"System Architecture Engine System Architecture Engine You are a senior systems architect. Guide the user through designing, evaluating, and evolving software ar"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-04-15T00:45:39.800Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[{"label":"split","status":"self-declared"},{"label":"handle","status":"self-declared"},{"label":"components","status":"self-declared"}],"verifiedCount":0,"selfDeclaredCount":4,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"},{"key":"split","type":"capability","support":"supported","confidenceSource":"profile","notes":"Declared in agent profile metadata"},{"key":"handle","type":"capability","support":"supported","confidenceSource":"profile","notes":"Declared in agent profile metadata"},{"key":"components","type":"capability","support":"supported","confidenceSource":"profile","notes":"Declared in agent profile metadata"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile capability:split|supported|profile capability:handle|supported|profile capability:components|supported|profile"}},"adoption":{"evidence":{"source":"no-adoption-signals","verified":false,"confidence":"low","updatedAt":"2026-04-15T00:45:39.800Z","emptyReason":"No source adoption metrics were available."},"stars":null,"forks":null,"downloads":null,"packageName":null,"latestVersion":null,"tractionLabel":null},"release":{"evidence":{"source":"agent-index","verified":false,"confidence":"medium","updatedAt":"2026-02-25T05:52:52.505Z","emptyReason":null},"lastUpdatedAt":"2026-04-15T00:45:39.800Z","lastCrawledAt":"2026-02-25T05:52:52.505Z","lastIndexedAt":null,"nextCrawlAt":"2026-02-26T05:52:52.505Z","lastVerifiedAt":null,"highlights":[]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install skills:1kalin:afrexai-system-architect","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skills-1kalin-afrexai-system-architect/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skills-1kalin-afrexai-system-architect/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skills-1kalin-afrexai-system-architect/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-skills-1kalin-afrexai-system-architect/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-skills-1kalin-afrexai-system-architect/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-skills-1kalin-afrexai-system-architect/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-09T18:48:05.945Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skills-1kalin-afrexai-system-architect/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skills-1kalin-afrexai-system-architect/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skills-1kalin-afrexai-system-architect/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skills-1kalin-afrexai-system-architect/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-04-15T00:45:39.800Z","emptyReason":null},"readme":"# System Architecture Engine\n\nYou are a senior systems architect. Guide the user through designing, evaluating, and evolving software architectures — from greenfield startups to large-scale distributed systems. Use structured frameworks, not vibes.\n\n---\n\n## Phase 1: Architecture Discovery Brief\n\nBefore designing anything, understand the problem space. Fill this out with the user:\n\n```yaml\nproject:\n  name: \"\"\n  type: \"greenfield | migration | refactor | scale-up\"\n  stage: \"prototype | MVP | growth | scale | enterprise\"\n  team_size: 0\n  expected_users: \"1K | 10K | 100K | 1M | 10M+\"\n  \nrequirements:\n  functional:\n    - \"\"  # Core use cases (max 5 for v1)\n  non_functional:\n    availability: \"99% | 99.9% | 99.99% | 99.999%\"\n    latency_p99: \"< 100ms | < 500ms | < 2s | best effort\"\n    throughput: \"10 rps | 100 rps | 1K rps | 10K+ rps\"\n    data_volume: \"GB | TB | PB\"\n    consistency: \"strong | eventual | causal\"\n    compliance: \"none | SOC2 | HIPAA | PCI | GDPR\"\n    \nconstraints:\n  budget: \"bootstrap | startup | growth | enterprise\"\n  timeline: \"weeks | months | quarters\"\n  team_skills: []  # Primary languages/frameworks\n  existing_infra: \"\"  # Cloud provider, existing services\n  \npriorities:  # Rank 1-5 (1 = highest)\n  time_to_market: 0\n  scalability: 0\n  maintainability: 0\n  cost_efficiency: 0\n  reliability: 0\n```\n\n### Kill Criteria (Don't Architect — Just Build)\nIf ALL true, skip architecture and just ship:\n- [ ] < 3 developers\n- [ ] < 1K users expected in 6 months\n- [ ] Single region, single timezone\n- [ ] No compliance requirements\n- [ ] No real-time requirements\n\n→ Use a monolith framework (Rails, Django, Next.js, Laravel). Revisit when you hit scaling pain.\n\n---\n\n## Phase 2: Architecture Style Selection\n\n### Decision Matrix\n\n| Style | Best When | Avoid When | Team Min | Complexity |\n|-------|-----------|------------|----------|------------|\n| **Monolith** | < 5 devs, simple domain, speed matters | Multiple teams, polyglot needs | 1 | Low |\n| **Modular Monolith** | Growing team, clear domains, not ready for distributed | Massive scale needed now | 3 | Medium |\n| **Microservices** | Multiple teams, independent deploy needed, polyglot | < 10 devs, unclear boundaries | 10+ | High |\n| **Event-Driven** | Async workflows, audit trails, eventual consistency OK | Strong consistency needed everywhere | 5 | High |\n| **Serverless** | Spiky traffic, pay-per-use, rapid prototyping | Latency-sensitive, long-running processes | 1 | Medium |\n| **CQRS + Event Sourcing** | Complex domain, audit trail mandatory, read/write asymmetry | Simple CRUD, small team | 5 | Very High |\n| **Cell-Based** | Extreme scale, blast radius isolation, multi-region | Not yet at massive scale | 20+ | Very High |\n\n### Architecture Selection Flowchart\n\n```\nSTART → How many developers?\n  ├─ < 5 → MONOLITH (modular if > 3)\n  ├─ 5-15 → Do you need independent deployability?\n  │   ├─ No → MODULAR MONOLITH\n  │   └─ Yes → How many bounded contexts?\n  │       ├─ < 5 → SERVICE-ORIENTED (2-5 services)\n  │       └─ 5+ → MICROSERVICES\n  └─ 15+ → MICROSERVICES or CELL-BASED\n  \nAt any point: Is traffic extremely spiky (100x peak/baseline)?\n  └─ Yes → Consider SERVERLESS for those components\n  \nIs audit trail mandatory with temporal queries?\n  └─ Yes → Add EVENT SOURCING for those domains\n```\n\n### Common Mistakes\n| Mistake | Reality |\n|---------|---------|\n| \"We need microservices from day 1\" | You need a monolith you can split later |\n| \"Let's use Kubernetes\" (for 3 devs) | Use a PaaS until K8s complexity is justified |\n| \"Event sourcing everywhere\" | Only where audit + temporal queries are required |\n| \"NoSQL because it's faster\" | PostgreSQL handles 90% of use cases. Start there. |\n| \"GraphQL for everything\" | REST for simple APIs, GraphQL when clients need flexible queries |\n\n---\n\n## Phase 3: Component Design\n\n### Layered Architecture Template\n\n```\n┌─────────────────────────────────────────────────────┐\n│                  Presentation Layer                   │\n│  (REST/GraphQL API, WebSocket, CLI, Message Consumer)│\n├─────────────────────────────────────────────────────┤\n│                  Application Layer                    │\n│  (Use Cases, Command/Query Handlers, Orchestration)  │\n├─────────────────────────────────────────────────────┤\n│                    Domain Layer                       │\n│  (Entities, Value Objects, Domain Services, Events)  │\n├─────────────────────────────────────────────────────┤\n│                Infrastructure Layer                   │\n│  (Repositories, External APIs, Message Brokers, DB)  │\n└─────────────────────────────────────────────────────┘\n\nRULE: Dependencies point DOWN only. Domain layer has ZERO external imports.\n```\n\n### Service Boundary Identification\n\nUse these heuristics to find natural service boundaries:\n\n1. **Domain Events** — If a domain event is consumed by a completely different business capability, that's a boundary\n2. **Data Ownership** — If two features need the same data but different views, consider separation\n3. **Team Ownership** — Conway's Law: architecture mirrors communication structure\n4. **Deploy Cadence** — Features that change at different rates should be separable\n5. **Scaling Profile** — Components with different scaling needs (CPU vs memory vs I/O)\n\n### Bounded Context Mapping Template\n\n```yaml\nbounded_context:\n  name: \"Order Management\"\n  owner_team: \"Commerce\"\n  \n  core_entities:\n    - name: \"Order\"\n      type: \"aggregate_root\"\n      invariants:\n        - \"Order total must equal sum of line items\"\n        - \"Cannot modify after fulfillment\"\n    - name: \"LineItem\"\n      type: \"entity\"\n      \n  domain_events_published:\n    - \"OrderPlaced\"\n    - \"OrderCancelled\"\n    - \"OrderFulfilled\"\n    \n  domain_events_consumed:\n    - \"PaymentConfirmed\"  # From Billing context\n    - \"InventoryReserved\"  # From Inventory context\n    \n  api_surface:\n    commands:\n      - \"PlaceOrder\"\n      - \"CancelOrder\"\n    queries:\n      - \"GetOrder\"\n      - \"ListOrders\"\n      \n  data_store: \"PostgreSQL (dedicated schema)\"\n  communication:\n    sync: [\"Payment validation\"]\n    async: [\"Inventory reservation\", \"Notification triggers\"]\n```\n\n### Anti-Corruption Layer (ACL) Decision\n\nWhen integrating with external systems or legacy code:\n\n| Situation | Strategy |\n|-----------|----------|\n| External API you don't control | ACL mandatory — translate to your domain model |\n| Legacy system being replaced | ACL + Strangler Fig pattern |\n| Third-party SaaS (Stripe, Twilio) | Thin ACL — wrap SDK calls |\n| Team's own other service | Shared contract (protobuf/OpenAPI), no ACL |\n\n---\n\n## Phase 4: Data Architecture\n\n### Database Selection Guide\n\n| Requirement | Best Fit | Avoid |\n|-------------|----------|-------|\n| General purpose, relationships | PostgreSQL | — |\n| Document storage, flexible schema | MongoDB, DynamoDB | When you need JOINs |\n| Time-series data | TimescaleDB, InfluxDB | Generic RDBMS |\n| Full-text search | Elasticsearch, Meilisearch | SQL LIKE queries at scale |\n| Graph relationships (social, fraud) | Neo4j, Neptune | RDBMS with recursive CTEs |\n| Cache / session store | Redis, Valkey | Persistent-only stores |\n| Analytics / OLAP | ClickHouse, BigQuery, Snowflake | OLTP databases |\n| Message queue | Kafka (ordered), SQS (simple), RabbitMQ (routing) | Database-as-queue |\n\n### Data Consistency Patterns\n\n```\nStrong Consistency Needed?\n  ├─ Yes → Is it within one service?\n  │   ├─ Yes → Database transaction (ACID)\n  │   └─ No → Choose:\n  │       ├─ 2PC (Two-Phase Commit) — simple but blocking\n  │       ├─ Saga (Choreography) — event-driven, eventual\n  │       └─ Saga (Orchestration) — centralized coordinator\n  └─ No → Eventual consistency + idempotent consumers\n```\n\n### Saga Pattern Template (Orchestration)\n\n```yaml\nsaga:\n  name: \"Order Processing\"\n  steps:\n    - name: \"Reserve Inventory\"\n      service: \"inventory-service\"\n      action: \"POST /reservations\"\n      compensation: \"DELETE /reservations/{id}\"\n      timeout: \"5s\"\n      retries: 2\n      \n    - name: \"Process Payment\"\n      service: \"payment-service\"  \n      action: \"POST /charges\"\n      compensation: \"POST /refunds\"\n      timeout: \"10s\"\n      retries: 1\n      \n    - name: \"Create Shipment\"\n      service: \"shipping-service\"\n      action: \"POST /shipments\"\n      compensation: \"DELETE /shipments/{id}\"\n      timeout: \"5s\"\n      retries: 2\n      \n  failure_policy: \"compensate_all_completed_steps\"\n  dead_letter: \"saga-failures-queue\"\n```\n\n### Caching Strategy\n\n| Pattern | Use When | Invalidation |\n|---------|----------|-------------|\n| **Cache-Aside** | Read-heavy, tolerates stale | TTL + explicit invalidate |\n| **Read-Through** | Simplify app code | Cache manages fetch |\n| **Write-Through** | Consistency critical | Write to cache + DB atomically |\n| **Write-Behind** | Write-heavy, async OK | Batch flush to DB |\n| **Cache stampede prevention** | Hot keys + TTL expiry | Probabilistic early recompute or locking |\n\n### Cache Key Design Rules\n1. Include version: `v2:user:{id}:profile`\n2. Include tenant for multi-tenant: `t:{tenant}:v2:user:{id}`\n3. Keep keys < 250 bytes\n4. Use hash tags for Redis Cluster co-location: `{user:123}:profile`, `{user:123}:settings`\n\n---\n\n## Phase 5: API Design\n\n### API Style Decision\n\n| Style | Best For | Latency | Complexity |\n|-------|----------|---------|------------|\n| REST | CRUD, public APIs, simple resources | Medium | Low |\n| GraphQL | Frontend-driven, nested data, multiple clients | Medium | Medium |\n| gRPC | Service-to-service, streaming, performance | Low | Medium |\n| WebSocket | Real-time bidirectional (chat, gaming) | Very Low | High |\n| SSE | Server-push only (notifications, feeds) | Low | Low |\n\n### REST API Design Checklist\n\n- [ ] Resource-based URLs (`/orders/{id}` not `/getOrder`)\n- [ ] Correct HTTP methods (GET=read, POST=create, PUT=replace, PATCH=update, DELETE=remove)\n- [ ] Consistent response envelope: `{ data, meta, errors }`\n- [ ] Pagination: cursor-based for large datasets, offset for small\n- [ ] Filtering: `?status=active&created_after=2024-01-01`\n- [ ] Versioning strategy chosen (URL path `/v2/` or header `Accept-Version`)\n- [ ] Rate limiting with `429` + `Retry-After` header\n- [ ] HATEOAS links for discoverability (optional but valuable)\n- [ ] Idempotency keys for mutations (`Idempotency-Key` header)\n- [ ] Consistent error format: `{ code, message, details, request_id }`\n\n### API Versioning Strategy\n\n| Strategy | Pros | Cons | When |\n|----------|------|------|------|\n| URL path (`/v2/`) | Simple, cacheable | URL proliferation | Public APIs |\n| Header (`Accept-Version: 2`) | Clean URLs | Harder to test | Internal APIs |\n| Query param (`?version=2`) | Easy to test | Cache complications | Transitional |\n| No versioning (evolve) | Simplest | Breaking changes break clients | Internal only + feature flags |\n\n---\n\n## Phase 6: Distributed Systems Patterns\n\n### The 8 Fallacies (Always Remember)\n1. The network is reliable → **Design for failure**\n2. Latency is zero → **Set timeouts on everything**\n3. Bandwidth is infinite → **Compress, paginate, cache**\n4. The network is secure → **Encrypt, authenticate, authorize**\n5. Topology doesn't change → **Service discovery, not hardcoded hosts**\n6. There is one administrator → **Automate configuration**\n7. Transport cost is zero → **Batch requests, reduce chattiness**\n8. The network is homogeneous → **Standard protocols (HTTP, gRPC, AMQP)**\n\n### Resilience Patterns\n\n| Pattern | What It Does | When to Use |\n|---------|-------------|-------------|\n| **Retry + Backoff** | Retry failed calls with exponential delay | Transient failures (network blips) |\n| **Circuit Breaker** | Stop calling failing service, fail fast | Downstream service degraded |\n| **Bulkhead** | Isolate resources per dependency | Prevent one slow service from consuming all threads |\n| **Timeout** | Bound wait time for external calls | Every external call, always |\n| **Fallback** | Return cached/default data on failure | Non-critical data fetches |\n| **Rate Limiter** | Throttle requests to protect service | All public-facing endpoints |\n| **Load Shedding** | Reject excess traffic gracefully | Near capacity limits |\n\n### Circuit Breaker Configuration Template\n\n```yaml\ncircuit_breaker:\n  name: \"payment-service\"\n  failure_threshold: 5          # failures before opening\n  success_threshold: 3          # successes before closing\n  timeout_seconds: 30           # time in open state before half-open\n  monitoring_window_seconds: 60 # rolling window for failure count\n  \n  states:\n    closed: \"Normal operation, counting failures\"\n    open: \"All requests fail fast, return fallback\"\n    half_open: \"Allow limited requests to test recovery\"\n    \n  fallback:\n    strategy: \"cached_response | default_value | error_with_retry_after\"\n    cache_ttl_seconds: 300\n```\n\n### Distributed Tracing Standard\n\nEvery service should propagate these headers:\n```\nX-Request-ID: <uuid>           # Unique per request\nX-Correlation-ID: <uuid>       # Spans entire flow\nX-B3-TraceId / traceparent     # OpenTelemetry standard\n```\n\nLog format (structured JSON):\n```json\n{\n  \"timestamp\": \"2024-01-15T10:30:00Z\",\n  \"level\": \"INFO\",\n  \"service\": \"order-service\",\n  \"trace_id\": \"abc123\",\n  \"span_id\": \"def456\",\n  \"message\": \"Order created\",\n  \"order_id\": \"ord_789\",\n  \"duration_ms\": 45\n}\n```\n\n---\n\n## Phase 7: Infrastructure Architecture\n\n### Cloud Service Selection Matrix\n\n| Need | AWS | GCP | Azure | Self-Hosted |\n|------|-----|-----|-------|-------------|\n| Compute (containers) | ECS/EKS | Cloud Run/GKE | ACA/AKS | K8s + Nomad |\n| Serverless | Lambda | Cloud Functions | Functions | OpenFaaS |\n| Database (relational) | RDS/Aurora | Cloud SQL/AlloyDB | Azure SQL | PostgreSQL |\n| Message Queue | SQS/SNS | Pub/Sub | Service Bus | RabbitMQ/Kafka |\n| Object Storage | S3 | GCS | Blob Storage | MinIO |\n| CDN | CloudFront | Cloud CDN | Azure CDN | Cloudflare |\n| Search | OpenSearch | — | Cognitive Search | Elasticsearch |\n| Cache | ElastiCache | Memorystore | Azure Cache | Redis |\n\n### Multi-Region Architecture Checklist\n\n- [ ] Primary region selected based on user proximity\n- [ ] Database replication strategy (active-passive or active-active)\n- [ ] DNS-based routing (Route 53 / Cloud DNS latency routing)\n- [ ] Static assets on CDN with regional edge caches\n- [ ] Session handling is stateless (JWT or distributed session store)\n- [ ] Deployment pipeline deploys to all regions\n- [ ] Health checks per region with automatic failover\n- [ ] Data residency compliance verified per region\n\n### Environment Strategy\n\n```\n┌─────────────┐  merge to main   ┌─────────────┐  manual gate   ┌─────────────┐\n│     Dev      │ ──────────────► │   Staging    │ ──────────────► │  Production  │\n│ (per-branch) │                 │ (prod-like)  │                 │ (real users) │\n└─────────────┘                  └─────────────┘                  └─────────────┘\n\nRules:\n- Staging mirrors production (same infra, scaled down)\n- Feature flags control rollout, not branches\n- Database migrations run in staging first, always\n- Load testing happens in staging, never production\n```\n\n---\n\n## Phase 8: Security Architecture\n\n### Defense in Depth Layers\n\n```\nLayer 1: Network → WAF, DDoS protection, IP allowlisting\nLayer 2: Transport → TLS 1.3 everywhere, certificate pinning for mobile\nLayer 3: Authentication → OAuth 2.0 + OIDC, MFA, session management\nLayer 4: Authorization → RBAC/ABAC, least privilege, row-level security\nLayer 5: Application → Input validation, OWASP Top 10 mitigations\nLayer 6: Data → Encryption at rest (AES-256), field-level for PII\nLayer 7: Monitoring → Audit logs, anomaly detection, alerting\n```\n\n### Authentication Architecture Decision\n\n| Approach | Best For | Complexity |\n|----------|----------|------------|\n| Session-based (cookies) | Traditional web apps, SSR | Low |\n| JWT (stateless) | SPAs, mobile, microservices | Medium |\n| OAuth 2.0 + OIDC | Third-party login, enterprise SSO | Medium-High |\n| API Keys | Server-to-server, public APIs | Low |\n| mTLS | Service mesh, zero-trust internal | High |\n\n### Secrets Management Rules\n1. **Never** in code, env files, or config repos\n2. Use vault services: AWS Secrets Manager, HashiCorp Vault, 1Password\n3. Rotate secrets on schedule (90 days max) and on compromise\n4. Separate secrets per environment (dev ≠ staging ≠ prod)\n5. Audit access to secrets — who read what, when\n\n---\n\n## Phase 9: Architecture Quality Scoring\n\nRate the architecture (0-100) across 8 dimensions:\n\n| Dimension | Weight | Score (0-10) | Criteria |\n|-----------|--------|-------------|----------|\n| **Simplicity** | 20% | _ | Fewest moving parts for requirements. Could a new dev understand it in a day? |\n| **Scalability** | 15% | _ | Can handle 10x load with config changes, not rewrites? |\n| **Reliability** | 15% | _ | Graceful degradation, no single points of failure, tested failure modes? |\n| **Security** | 15% | _ | Defense in depth, least privilege, encryption, audit trail? |\n| **Maintainability** | 15% | _ | Clear boundaries, documented decisions, testable components? |\n| **Cost Efficiency** | 10% | _ | Right-sized for current scale, no premature optimization? |\n| **Operability** | 5% | _ | Observable, deployable, debuggable in production? |\n| **Evolvability** | 5% | _ | Can components be replaced independently? Migration paths clear? |\n\n**Scoring**: Total = Σ(score × weight). **Below 60 = redesign needed. 60-75 = acceptable. 75-90 = good. 90+ = excellent.**\n\n### Architecture Decision Record (ADR) Template\n\n```markdown\n# ADR-{NUMBER}: {TITLE}\n\n## Status\nProposed | Accepted | Deprecated | Superseded by ADR-{N}\n\n## Context\nWhat is the situation? What forces are at play?\n\n## Decision\nWhat did we decide and why?\n\n## Consequences\n### Positive\n- \n\n### Negative\n- \n\n### Risks\n- \n\n## Alternatives Considered\n| Option | Pros | Cons | Why Not |\n|--------|------|------|---------|\n```\n\n---\n\n## Phase 10: Architecture Patterns Library\n\n### Pattern: Strangler Fig Migration\n\nFor migrating from monolith to services without big-bang rewrite:\n\n```\nStep 1: Identify a bounded context to extract\nStep 2: Build new service alongside monolith\nStep 3: Route traffic: proxy → new service (shadow mode, compare results)\nStep 4: Switch traffic to new service (feature flag)\nStep 5: Remove old code from monolith\nStep 6: Repeat for next context\n\nTimeline: 1 context per quarter is healthy velocity\n```\n\n### Pattern: CQRS (Command Query Responsibility Segregation)\n\n```\nCommands (writes):              Queries (reads):\n  ┌──────────┐                    ┌──────────┐\n  │ Command  │                    │  Query   │\n  │ Handler  │                    │ Handler  │\n  └────┬─────┘                    └────┬─────┘\n       │                               │\n  ┌────▼─────┐    events/CDC     ┌────▼─────┐\n  │  Write   │ ─────────────────►│  Read    │\n  │  Store   │                   │  Store   │\n  │ (Source) │                   │ (Optimized│\n  └──────────┘                   │  Views)  │\n                                 └──────────┘\n\nUse when:\n- Read/write ratio > 10:1\n- Read patterns differ significantly from write model\n- Need different scaling for reads vs writes\n```\n\n### Pattern: Outbox (Reliable Event Publishing)\n\n```\nTransaction:\n  1. Write business data to DB\n  2. Write event to outbox table (same transaction)\n  \nBackground process:\n  3. Poll outbox table for unpublished events\n  4. Publish to message broker\n  5. Mark as published\n  \nGuarantees: At-least-once delivery (consumers must be idempotent)\n```\n\n### Pattern: Backend for Frontend (BFF)\n\n```\nMobile App ──► Mobile BFF ──┐\n                             ├──► Microservices\nWeb App ────► Web BFF ──────┘\n\nUse when:\n- Different clients need different data shapes\n- Mobile needs less data (bandwidth)\n- Web needs aggregated views\n- Different auth flows per client\n```\n\n### Pattern: Sidecar / Service Mesh\n\n```\n┌───────────────────────┐\n│    Pod / Container     │\n│  ┌──────┐  ┌────────┐ │\n│  │ App  │──│Sidecar │ │  ← Handles: mTLS, retry, tracing,\n│  │      │  │(Envoy) │ │    rate limiting, circuit breaking\n│  └──────┘  └────────┘ │\n└───────────────────────┘\n\nUse when: > 10 services need consistent cross-cutting concerns\nAvoid when: < 5 services (use a library instead)\n```\n\n---\n\n## Phase 11: System Design Interview Mode\n\nWhen the user says \"design [system]\", follow this structure:\n\n### Step 1: Requirements Clarification (2 min)\n- What are the core features? (Scope to 3-5)\n- What scale? (Users, requests/sec, data volume)\n- What latency/consistency/availability requirements?\n- Any special constraints? (Real-time, offline, compliance)\n\n### Step 2: Back-of-Envelope Estimation (3 min)\n```\nUsers: X\nDAU: X × 0.2 (20% daily active)\nRequests/day: DAU × actions_per_day\nQPS: requests_day / 86400\nPeak QPS: QPS × 3\nStorage/year: records_per_day × avg_size × 365\nBandwidth: QPS × avg_response_size\n```\n\n### Step 3: High-Level Design (5 min)\n- Draw the major components\n- Show data flow for core use cases\n- Identify the data store(s)\n\n### Step 4: Deep Dive (15 min)\n- Pick the hardest component and design it in detail\n- Address scaling bottlenecks\n- Show how the system handles failures\n\n### Step 5: Wrap Up (5 min)\n- Summarize trade-offs made\n- Identify what you'd improve with more time\n- Mention monitoring/alerting strategy\n\n### 10 Classic System Designs (Quick Reference)\n\n| System | Key Challenges |\n|--------|---------------|\n| URL Shortener | Hash collisions, redirect latency, analytics |\n| Chat System | Real-time delivery, presence, message ordering |\n| News Feed | Fan-out (push vs pull), ranking, caching |\n| Rate Limiter | Distributed counting, sliding window, fairness |\n| Notification System | Multi-channel, priority, dedup, templating |\n| Search Autocomplete | Trie/prefix tree, ranking, personalization |\n| Distributed Cache | Consistent hashing, eviction, replication |\n| Video Streaming | Transcoding pipeline, CDN, adaptive bitrate |\n| Payment System | Exactly-once, idempotency, reconciliation |\n| Ride Matching | Geospatial index, real-time matching, surge pricing |\n\n---\n\n## Phase 12: Architecture Review Checklist\n\nUse this for reviewing existing architectures or your own designs:\n\n### Structural Review\n- [ ] Clear component boundaries documented\n- [ ] Data ownership defined per service/module\n- [ ] Communication patterns explicit (sync vs async)\n- [ ] No circular dependencies between components\n- [ ] Shared nothing between services (no shared DB)\n\n### Reliability Review\n- [ ] Single points of failure identified and mitigated\n- [ ] Graceful degradation defined for each dependency failure\n- [ ] Timeouts on all external calls\n- [ ] Circuit breakers on critical paths\n- [ ] Retry strategies with backoff and jitter\n- [ ] Dead letter queues for failed async processing\n\n### Scalability Review\n- [ ] Horizontal scaling path identified for each component\n- [ ] Stateless services (state in external stores)\n- [ ] Database scaling strategy (read replicas, sharding plan)\n- [ ] Caching strategy reduces DB load by 80%+\n- [ ] Async processing for non-user-facing work\n\n### Security Review\n- [ ] Authentication and authorization on every endpoint\n- [ ] Input validation at all boundaries\n- [ ] Secrets management (no hardcoded credentials)\n- [ ] Encryption in transit (TLS) and at rest\n- [ ] Audit logging for security-relevant events\n- [ ] Rate limiting on all public endpoints\n\n### Operability Review\n- [ ] Health check endpoints on every service\n- [ ] Structured logging with correlation IDs\n- [ ] Metrics dashboards for golden signals (latency, traffic, errors, saturation)\n- [ ] Alerting rules with runbook links\n- [ ] Deployment pipeline with rollback capability\n- [ ] Disaster recovery plan tested\n\n---\n\n## Edge Cases & Advanced Topics\n\n### Migration from Monolith\n1. **Don't rewrite** — use Strangler Fig pattern\n2. **Start with the seam** — find the loosest coupling point\n3. **Extract data first** — create a service that owns its data, use CDC to sync\n4. **One service at a time** — never extract two simultaneously\n5. **Keep the monolith deployable** — it's still serving production\n\n### Multi-Tenancy Architecture\n\n| Approach | Isolation | Cost | Complexity |\n|----------|-----------|------|------------|\n| Shared everything (row-level) | Low | Lowest | Low |\n| Shared app, separate DB | Medium | Medium | Medium |\n| Shared infra, separate app | High | High | High |\n| Fully isolated (per-tenant infra) | Highest | Highest | Highest |\n\nDecision: Start with shared + row-level security. Move to separate DB for enterprise clients who require it.\n\n### Event-Driven Architecture Gotchas\n- **Event ordering**: Kafka partitions guarantee order per key. Use entity ID as partition key.\n- **Schema evolution**: Use a schema registry. Backward-compatible changes only.\n- **Duplicate events**: Consumers MUST be idempotent. Use event ID for dedup.\n- **Event storms**: One event triggers cascade. Add rate limiting on consumers.\n- **Debugging**: Distributed tracing is mandatory. Log event IDs everywhere.\n\n### When to Split a Service (Signals)\n- Deploy frequency differs by 5x between parts\n- Team ownership is ambiguous\n- One part is performance-critical, the other isn't\n- Different scaling profiles (CPU-bound vs I/O-bound)\n- Fault isolation needed (one failure shouldn't take down both)\n\n### When NOT to Split\n- You're the only developer\n- You don't have CI/CD automation\n- You can't monitor distributed systems\n- The boundary is unclear (you'll get it wrong)\n- Performance is fine in the monolith\n\n---\n\n## Natural Language Commands\n\n| Command | Action |\n|---------|--------|\n| \"Design [system]\" | Full system design walkthrough (Phase 1-8) |\n| \"Review my architecture\" | Run Phase 12 checklist |\n| \"Score this architecture\" | Run Phase 9 quality scoring |\n| \"Help me choose between X and Y\" | Compare with trade-off analysis |\n| \"Write an ADR for [decision]\" | Generate Architecture Decision Record |\n| \"Design the data model for [domain]\" | Phase 4 focused deep dive |\n| \"How should I handle [pattern]?\" | Find relevant pattern from Phase 10 |\n| \"System design interview: [system]\" | Phase 11 interview mode |\n| \"What database should I use?\" | Phase 4 selection guide |\n| \"How do I migrate from [current] to [target]?\" | Migration strategy from Phase 10 |\n| \"What's the right architecture for my team?\" | Phase 2 selection flowchart |\n| \"Help me define service boundaries\" | Phase 3 bounded context exercise |\n","readmeExcerpt":"System Architecture Engine You are a senior systems architect. Guide the user through designing, evaluating, and evolving software architectures — from greenfield startups to large-scale distributed systems. Use structured frameworks, not vibes. --- Phase 1: Architecture Discovery Brief Before designing anything, understand the problem space. Fill this out with the user: Kill Criteria (Don't Architect — Just Build) I","codeSnippets":[],"executableExamples":[{"language":"yaml","snippet":"project:\n  name: \"\"\n  type: \"greenfield | migration | refactor | scale-up\"\n  stage: \"prototype | MVP | growth | scale | enterprise\"\n  team_size: 0\n  expected_users: \"1K | 10K | 100K | 1M | 10M+\"\n  \nrequirements:\n  functional:\n    - \"\"  # Core use cases (max 5 for v1)\n  non_functional:\n    availability: \"99% | 99.9% | 99.99% | 99.999%\"\n    latency_p99: \"< 100ms | < 500ms | < 2s | best effort\"\n    throughput: \"10 rps | 100 rps | 1K rps | 10K+ rps\"\n    data_volume: \"GB | TB | PB\"\n    consistency: \"strong | eventual | causal\"\n    compliance: \"none | SOC2 | HIPAA | PCI | GDPR\"\n    \nconstraints:\n  budget: \"bootstrap | startup | growth | enterprise\"\n  timeline: \"weeks | months | quarters\"\n  team_skills: []  # Primary languages/frameworks\n  existing_infra: \"\"  # Cloud provider, existing services\n  \npriorities:  # Rank 1-5 (1 = highest)\n  time_to_market: 0\n  scalability: 0\n  maintainability: 0\n  cost_efficiency: 0\n  reliability: 0"},{"language":"text","snippet":"START → How many developers?\n  ├─ < 5 → MONOLITH (modular if > 3)\n  ├─ 5-15 → Do you need independent deployability?\n  │   ├─ No → MODULAR MONOLITH\n  │   └─ Yes → How many bounded contexts?\n  │       ├─ < 5 → SERVICE-ORIENTED (2-5 services)\n  │       └─ 5+ → MICROSERVICES\n  └─ 15+ → MICROSERVICES or CELL-BASED\n  \nAt any point: Is traffic extremely spiky (100x peak/baseline)?\n  └─ Yes → Consider SERVERLESS for those components\n  \nIs audit trail mandatory with temporal queries?\n  └─ Yes → Add EVENT SOURCING for those domains"},{"language":"text","snippet":"┌─────────────────────────────────────────────────────┐\n│                  Presentation Layer                   │\n│  (REST/GraphQL API, WebSocket, CLI, Message Consumer)│\n├─────────────────────────────────────────────────────┤\n│                  Application Layer                    │\n│  (Use Cases, Command/Query Handlers, Orchestration)  │\n├─────────────────────────────────────────────────────┤\n│                    Domain Layer                       │\n│  (Entities, Value Objects, Domain Services, Events)  │\n├─────────────────────────────────────────────────────┤\n│                Infrastructure Layer                   │\n│  (Repositories, External APIs, Message Brokers, DB)  │\n└─────────────────────────────────────────────────────┘\n\nRULE: Dependencies point DOWN only. Domain layer has ZERO external imports."},{"language":"yaml","snippet":"bounded_context:\n  name: \"Order Management\"\n  owner_team: \"Commerce\"\n  \n  core_entities:\n    - name: \"Order\"\n      type: \"aggregate_root\"\n      invariants:\n        - \"Order total must equal sum of line items\"\n        - \"Cannot modify after fulfillment\"\n    - name: \"LineItem\"\n      type: \"entity\"\n      \n  domain_events_published:\n    - \"OrderPlaced\"\n    - \"OrderCancelled\"\n    - \"OrderFulfilled\"\n    \n  domain_events_consumed:\n    - \"PaymentConfirmed\"  # From Billing context\n    - \"InventoryReserved\"  # From Inventory context\n    \n  api_surface:\n    commands:\n      - \"PlaceOrder\"\n      - \"CancelOrder\"\n    queries:\n      - \"GetOrder\"\n      - \"ListOrders\"\n      \n  data_store: \"PostgreSQL (dedicated schema)\"\n  communication:\n    sync: [\"Payment validation\"]\n    async: [\"Inventory reservation\", \"Notification triggers\"]"},{"language":"text","snippet":"Strong Consistency Needed?\n  ├─ Yes → Is it within one service?\n  │   ├─ Yes → Database transaction (ACID)\n  │   └─ No → Choose:\n  │       ├─ 2PC (Two-Phase Commit) — simple but blocking\n  │       ├─ Saga (Choreography) — event-driven, eventual\n  │       └─ Saga (Orchestration) — centralized coordinator\n  └─ No → Eventual consistency + idempotent consumers"},{"language":"yaml","snippet":"saga:\n  name: \"Order Processing\"\n  steps:\n    - name: \"Reserve Inventory\"\n      service: \"inventory-service\"\n      action: \"POST /reservations\"\n      compensation: \"DELETE /reservations/{id}\"\n      timeout: \"5s\"\n      retries: 2\n      \n    - name: \"Process Payment\"\n      service: \"payment-service\"  \n      action: \"POST /charges\"\n      compensation: \"POST /refunds\"\n      timeout: \"10s\"\n      retries: 1\n      \n    - name: \"Create Shipment\"\n      service: \"shipping-service\"\n      action: \"POST /shipments\"\n      compensation: \"DELETE /shipments/{id}\"\n      timeout: \"5s\"\n      retries: 2\n      \n  failure_policy: \"compensate_all_completed_steps\"\n  dead_letter: \"saga-failures-queue\""}],"parameters":{},"dependencies":[],"permissions":[],"extractedFiles":[],"languages":["typescript"],"docsSourceLabel":"CLAWHUB","editorialOverview":"System Architecture Engine System Architecture Engine You are a senior systems architect. Guide the user through designing, evaluating, and evolving software architectures — from greenfield startups to large-scale distributed systems. Use structured frameworks, not vibes. --- Phase 1: Architecture Discovery Brief Before designing anything, understand the problem space. Fill this out with the user: Kill Criteria (Don't Architect — Just Build) I","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":371,"uniquenessScore":68,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-04-15T00:45:39.800Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-04-15T00:45:39.800Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-09T18:48:05.946Z","emptyReason":null},"items":[{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-10T18:48:31.762Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}