svallejo-dev/architecture
Large-scale systems design, starting from what already exists or, without metrics, from the business archetype: system design sparring as a delta (AS-IS → TO-BE → migration) or a PoC plan, a parallel red team, capacity computed in code with scenarios and thresholds, DDD strategic design, business archetypes and a curated catalog of building blocks.
Reference catalog of distributed-systems building blocks (API, storage, caching, consistency, messaging, scheduling, resilience, scaling, observability, logging, load balancing, DNS, CDN, IDs, counters, blobs, search, service decomposition, requirements) with options, trade-offs and behavior under stress. system-design and design-stress-test load it; also use it for a one-off question about one of those components.
Business archetypes for designing without prior metrics (exploratory design, PoC, new product). Each archetype (streaming and media, fintech and payments, ticketing and live events, e-commerce and marketplace, social and messaging, B2B SaaS, IoT and telemetry, mobility and logistics, healthtech, AI platform, internal event platform) gives the dominant forces, shape of the load, invariants, typical subdomains, reference architecture, failure modes and PoC hypotheses. system-design, capacity-estimation, design-stress-test and strategic-design load it; also use it when the user says "it is like Netflix/Stripe/Uber" or describes a product without numbers.
Capacity estimation with numbers computed in code, not in prose. It starts from measured metrics when the system exists, or from order-of-magnitude scenarios and decision thresholds when there are no metrics (exploratory design, PoC), leaning on the business archetype. Covers QPS, storage, bandwidth, Little's law, utilization and queues, fan-out and tail latency, composed availability, shards, backlog and burn rate. Use it when a decision depends on scale ("will it hold?", "how many instances?", "do we need to shard?", "capacity planning", "back-of-the-envelope").
Red team for a design or an existing system. It launches parallel subagents, each with an attack family (load, dependencies, data, changes, infrastructure, operations, abuse), seeded with the system's real incidents and verified against its code and configuration; it returns a risk matrix with failure mode, detection and mitigation. Use it when the user asks for a "stress test", "red team", "what can go wrong?", "pre-mortem", "will this hold?" or a resilience review.
Strategic design (DDD) to decide the boundaries of services and contexts: subdomain classification (core, supporting, generic), a context map with named patterns (Anticorruption Layer, Open Host Service, Published Language, Customer-Supplier, Conformist, Shared Kernel, Partnership, Separate Ways), data ownership and team alignment. It starts from the current map (AS-IS) before the target. Use it when discussing service boundaries, integrations between systems, a legacy migration, "context map", "bounded contexts", "subdomains" or "where does this responsibility go?".
Production-grade, large-scale system design sparring, also for exploratory designs and PoCs without metrics. It starts from what already exists (the current system, a similar documented system or the business archetype) and designs as a delta, current state → target → migration path, with computed numbers, alternatives with explicit trade-offs, a red team and recorded decisions. Use it when the user wants to design, redesign or evaluate an architecture ("design", "how do we scale X?", "system design", "architecture for…", "review this RFC/design", "how do we migrate…?").