{
  "strand_id": "tech",
  "name": "Tech Strand – Engineering architecture, patterns, and standards",
  "purpose": {
    "summary": "Define the technical backbone of the product so it can scale, stay reliable, and evolve without rewriting the whole system.",
    "goals": [
      "Choose a tech stack and architecture that matches product, UX, and business constraints.",
      "Design data models and storage that will survive 10–100x growth.",
      "Standardize patterns, libraries, and integrations to reduce chaos and tech-debt.",
      "Bake in reliability, observability, and security from day one."
    ]
  },

  "inputs_from_other_strands": {
    "product_strand": [
      "Core jobs-to-be-done",
      "Key workflows (e.g., real-time messaging, search, file sharing)",
      "Roadmap: features that stress scale (e.g., large enterprises, cross-org channels)"
    ],
    "ux_strand": [
      "Latency budgets (e.g., <200ms message send feedback)",
      "Offline / presence expectations",
      "Collaboration models (DM, channels, threads, reactions)"
    ],
    "brand_strand": [
      "Reliability expectations (\"always on\" vs \"good enough\")",
      "Security / compliance promises (e.g., enterprise-grade, data residency)"
    ]
  },

  "decision_axes": {
    "1_runtime_and_service_stack": {
      "questions": [
        "What languages and runtimes best match our real-time + web-heavy workload?",
        "Do we start monolith-first or services-from-day-one?",
        "How do we avoid painting ourselves into a scale corner?"
      ],
      "options_framework": {
        "runtime_choices": [
          "PHP/Hack + HHVM or similar (fast to build, proven at scale for web apps)",
          "Java / JVM (for high-throughput, strongly-typed core services)",
          "Node.js (good for gateway / edge / API fan-out)",
          "Elixir/Go (for real-time, long-lived connections, low-latency services)"
        ],
        "architecture_patterns": [
          "Monolith-first with clear module boundaries",
          "Modular monolith evolving into microservices",
          "Cellular / cell-based architecture for blast-radius isolation",
          "Strict BFF (Backend-for-Frontend) layer for clients"
        ]
      },
      "slack_example": {
        "primary_backends": {
          "application_layer": [
            "PHP/Hack running on HHVM for core web application logic"
          ],
          "real_time_services": [
            "Core real-time messaging services written in Java (Channel, Gateway, Admin, Presence servers) handling WebSocket connections and event fanout"
          ],
          "voice_video": [
            "Elixir used for voice and video calling services"
          ]
        },
        "notes": [
          "Slack evolved from a LAMP-style stack to Hacklang on HHVM for better performance and static typing while keeping PHP compatibility.",
          "Dedicated Java services now power high-throughput real-time messaging for millions of concurrent users."
        ]
      }
    },

    "2_client_stack_and_delivery": {
      "questions": [
        "What clients do we support (web, desktop, mobile)?",
        "How do we share logic and design tokens across clients?"
      ],
      "options_framework": {
        "web": [
          "React (+ Redux or modern equivalent) as the primary web UI framework",
          "Design tokens + component library mapped from UI Strand"
        ],
        "desktop": [
          "Electron wrapper around the web app for cross-platform desktop",
          "Shared codebase with web to minimize divergence"
        ],
        "mobile": [
          "Native iOS (Swift) and Android (Kotlin) for performance-critical UX",
          "Shared API/BFF contracts with web/desktop"
        ]
      },
      "slack_example": {
        "web": "React front-end with a Node.js-based core engine and Redux-style state management.",
        "desktop": "Electron-based desktop clients wrapping the React app.",
        "mobile": "Native iOS (Objective-C/Swift) and Android apps consuming the same APIs."
      }
    },

    "3_data_layer_and_database_strategy": {
      "questions": [
        "What is the shape of our data (messages, channels, files, orgs, users)?",
        "What are our consistency vs latency requirements?",
        "At what scale will a single database fall over?"
      ],
      "data_model_basics": {
        "core_entities": [
          "User",
          "Workspace / Organization",
          "Channel",
          "Membership (User<->Channel, User<->Workspace)",
          "Message (with thread / reply chains)",
          "File / Attachment",
          "Reaction / Emoji",
          "App / Bot / Integration"
        ],
        "design_principles": [
          "Normalize core relationships (users, channels, workspaces).",
          "Denormalize for read-heavy paths (e.g., channel membership summaries, unread counters).",
          "Add append-only logs for critical events (audit & recovery)."
        ]
      },
      "storage_strategy_framework": {
        "mvp_scale": {
          "description": "Single-region, single primary DB",
          "pattern": "Single MySQL/Postgres instance with read replicas",
          "capacity_envelope": "Up to ~10–50k DAU with careful indexing and caching"
        },
        "growth_scale": {
          "description": "Horizontal scaling via sharding",
          "pattern": "Sharded MySQL (e.g., via Vitess) or equivalent, partitioned by workspace or user-id",
          "capacity_envelope": "100k–10M+ DAU, billions of messages"
        },
        "slack_scale": {
          "description": "Massively sharded MySQL cluster with query router layer",
          "pattern": "Vitess-managed MySQL shards, connection pooling, query routing, and online migrations"
        }
      },
      "slack_example": {
        "primary_database": {
          "engine": "MySQL",
          "scaling_layer": "Vitess for sharding, topology management, connection pooling, and online schema changes",
          "notes": [
            "MySQL is the backbone of Slack’s data storage infrastructure, handling billions of queries per day across thousands of sharded hosts.",
            "Vitess now serves ~99% of Slack’s query load and is the storage bet for the foreseeable future."
          ]
        },
        "caching": {
          "layer": "Memcached with mcrouter for distributed caching and routing",
          "purpose": [
            "Reduce read pressure on MySQL/Vitess.",
            "Speed up hot paths such as channel lists, message histories, and presence data."
          ]
        },
        "async_queues_and_streams": {
          "technologies": [
            "Kafka for event streaming and async processing",
            "Redis for task queues and short-lived data"
          ],
          "usage_examples": [
            "Fanout of events to connected clients",
            "Background jobs like indexing, notifications, and analytics ingestion"
          ]
        },
        "analytics_and_warehouse": {
          "stack": [
            "Presto, Spark, Airflow, Hadoop, and Kafka powering data warehousing and analytics workloads"
          ],
          "purpose": [
            "Usage analytics, billing, and long-term product insights."
          ]
        }
      }
    },

    "4_scalability_reliability_and_topology": {
      "questions": [
        "How do we design for N× growth in users, channels, and messages?",
        "What’s our fault isolation strategy?",
        "How do we handle the thundering herd when huge orgs reconnect?"
      ],
      "patterns_framework": {
        "scale_patterns": [
          "Horizontal sharding by workspace or tenant",
          "Edge gateways for WebSockets and API traffic",
          "Fanout services for real-time event distribution",
          "Backpressure and rate-limiting on all external edges"
        ],
        "reliability_patterns": [
          "Multi-AZ deployment (at minimum) with automated failover",
          "Cellular architecture: partition traffic into “cells” to limit blast radius",
          "Graceful degradation (e.g., search might be slow but messaging stays up)",
          "Feature flags to decouple deploy from release"
        ],
        "infra_basics": [
          "Run on cloud infra like AWS (EC2, load balancers, managed network, storage).",
          "Per-env isolation: dev, staging, prod with similar topology."
        ]
      },
      "slack_example": {
        "cloud": "Slack runs its dev and app environments on Amazon EC2-based infrastructure.",
        "real_time_topology": {
          "services": [
            "Gateway Servers manage WebSocket connections from clients.",
            "Channel Servers handle routing and fanout of messages per channel.",
            "Presence Servers maintain online/offline state.",
            "Admin Servers coordinate control-plane responsibilities."
          ],
          "characteristics": [
            "Designed to handle billions of daily messages and millions of concurrent connections.",
            "Optimized to solve thundering herd problems when large organizations reconnect at once."
          ]
        },
        "db_topology": {
          "design": "Vitess-managed MySQL shards deployed as large clusters.",
          "latency": "Average query latency around a few milliseconds thanks to co-located proxy and shards."
        }
      }
    },

    "5_integration_surface_and_platform": {
      "questions": [
        "What’s the official way external systems talk to us?",
        "How do we prevent every integration from becoming a one-off hack?"
      ],
      "patterns_framework": {
        "integration_contracts": [
          "REST + WebSocket APIs for core product usage.",
          "Events API (webhooks) for external consumers.",
          "Slash commands, bots, and app framework as standardized integration primitives."
        ],
        "auth_and_security": [
          "OAuth 2.0 for app authentication.",
          "Fine-grained scopes for permissions.",
          "Rate limits and quotas to protect core systems."
        ],
        "versioning_and_lifecycle": [
          "API versioning strategy (v1, v2… with deprecation windows).",
          "App review / validation workflow."
        ]
      },
      "slack_example": {
        "public_platform": {
          "sdks_and_frameworks": [
            "Bolt framework (Python, Node.js, Java) built on top of Slack SDKs.",
            "Slack Web API and Events API as primary integration points."
          ],
          "capabilities": [
            "Slash commands, interactive components, message actions.",
            "Workflow integrations, file uploads, and more."
          ]
        },
        "internal_integration_policy": {
          "principles": [
            "All internal integrations should go through the same platform abstractions used by external apps.",
            "No direct DB access for external systems; everything via APIs/events."
          ]
        }
      }
    },

    "6_engineering_standards_tooling_and_observability": {
      "questions": [
        "How do teams ship fast without breaking everything?",
        "How do we see and debug issues across thousands of services and shards?"
      ],
      "standards_framework": {
        "code_quality": [
          "Static typing where possible (Hack, Java, TypeScript).",
          "Mandatory code review and automated testing pipelines.",
          "Service templates with default logging/metrics/tracing baked in."
        ],
        "ci_cd": [
          "Automated test + build pipelines for every change.",
          "Canary and phased rollouts to limit blast radius.",
          "Rollbacks and feature flags as safety net."
        ],
        "observability": [
          "Centralized logging (structured logs).",
          "Metrics (latency, error rates, saturation) per service and per cell.",
          "Distributed tracing across APIs and async flows."
        ],
        "dev_environments": [
          "Remote dev environments running app replicas on EC2 (or equivalent), mirroring production topology closely.",
          "Per-developer or per-team sandboxes for experimentation."
        ]
      },
      "slack_example": {
        "dev_envs": [
          "Slack provides remote development environments hosted on Amazon EC2, each running a full copy of the Slack application and its dependent services for engineers to test changes in realistic conditions."
        ],
        "type_safety_and_quality": [
          "Migration from plain PHP to Hack introduced static typing, helping detect errors early and support long-term maintainability."
        ]
      }
    }
  },

  "capacity_planning": {
    "tiers": [
      {
        "name": "Tier 0 – Prototype",
        "max_users": 5000,
        "architecture_profile": "Single-region monolith, one primary DB, minimal sharding, basic caching.",
        "recommended_stack": {
          "backend": "Rails/Laravel/Django/Node monolith or Hack/PHP monolith.",
          "db": "Single MySQL/Postgres instance + read replicas.",
          "cache": "Single Redis/Memcached node.",
          "messaging": "Simple WebSocket server or long polling."
        }
      },
      {
        "name": "Tier 1 – Growth",
        "max_users": 250000,
        "architecture_profile": "Modular monolith or early microservices, dedicated real-time layer, heavy caching, background jobs.",
        "recommended_stack": {
          "backend": "Hack/PHP or Java + Node gateways.",
          "db": "Horizontally partitioned MySQL/Postgres (schema-based or early Vitess).",
          "cache": "Memcached/Redis clusters with routing (e.g., mcrouter).",
          "queues": "Kafka/RabbitMQ/Redis streams for async tasks."
        }
      },
      {
        "name": "Tier 2 – Slack-scale",
        "max_users": "10M+ DAU, billions of messages/day",
        "architecture_profile": "Cellular architecture, sharded MySQL via Vitess, dedicated Java real-time services, robust platform layer.",
        "recommended_stack": {
          "backend": [
            "Hack/PHP app layer",
            "Java real-time services",
            "Elixir for voice/video"
          ],
          "db": "Vitess-managed MySQL shards for all critical data.",
          "cache": "Large Memcached + mcrouter clusters.",
          "streaming": "Kafka for events; Redis for fast queues.",
          "infra": "AWS or equivalent with EC2-style instances, autoscaling groups, multi-AZ deployments."
        }
      }
    ]
  },

  "third_party_and_integrations_catalog": {
    "categories": [
      {
        "name": "Messaging and Queues",
        "examples": ["Kafka", "Redis Streams", "SQS"],
        "selection_criteria": [
          "Throughput requirements",
          "Ordering guarantees",
          "Operational complexity"
        ]
      },
      {
        "name": "Search and Indexing",
        "examples": ["SolrCloud", "Elasticsearch", "OpenSearch"],
        "selection_criteria": [
          "Multi-tenant indexing strategy",
          "Latency vs freshness tradeoffs"
        ]
      },
      {
        "name": "Analytics and Warehousing",
        "examples": ["Presto", "Spark", "Airflow", "Hadoop", "Snowflake/BigQuery"],
        "selection_criteria": [
          "Query patterns (ad-hoc vs dashboards)",
          "Data retention requirements",
          "Cost vs flexibility"
        ]
      },
      {
        "name": "Monitoring and Observability",
        "examples": ["Prometheus+Grafana", "Datadog", "New Relic", "OpenTelemetry"],
        "selection_criteria": [
          "Support for distributed tracing",
          "Multi-service correlation"
        ]
      }
    ]
  }
}