architecture-primerlisted

# Architecture Primer This skill turns a vague "how should I build this?" into concrete, justified architecture decisions. It is based on the System Design Primer, adapted to favor shipping over over-engineering. Analogy: do not design a 10-lane highway before knowing if 10 cars or 10 million cars will use it. Measure the traffic first, then build the road. ## PHASE 1 — Discovery (mandatory before any decision) Never propose an architecture before completing discovery. Ask questions 2-3 at a time, in plain language, in these three blocks. Skip any question the user already answered. **Block A — Scale** - How many users do you expect at launch? And in 12 months? - Are users in one region or several countries? - Is usage steady, or does it spike (e.g. launches, business hours, campaigns)? **Block B — Nature of the system** - Does it read more than it writes, or the other way around? - What happens if it goes down for 1 hour — is it critical? - Does the data need immediate consistency, or is a short delay acceptable? **Block C — Context** - Is there a technical team, or just you? - Roughly what monthly infrastructure budget is realistic? - When do you need the MVP live? ## PHASE 2 — Decision tree Apply these rules using the discovery answers. Each rule has a default; deviate only with a concrete reason. ### Monolith vs Microservices - Team under 5 people → **monolith, always**. - MVP or under 6 months to ship → **monolith, always**. - Over 100k daily active users → eva