system-design

Design a backend/distributed system end-to-end, or review one, at a staff/principal level — right-sized for its actual scale, neither over-engineered nor fragile. Use this skill whenever the user is designing a new system or service, sketching an architecture, doing capacity/back-of- envelope estimation, choosing between SQL/NoSQL, adding caching/queues/sharding/replication, deciding push vs pull / sync vs async / strong vs eventual consistency, sizing for growth, or reviewing an existing architecture for scalability, reliability, cost, and bottlenecks — even if they never say "system design". Trigger on requests like "design a URL shortener / chat / feed / notification system", "how should I architect this service", "will this scale", "how do I handle this many users/requests", "should this be a queue or a cron", "how do I make this reliable", "estimate the capacity", or when planning any service that touches traffic, storage, consistency, or failure at scale. This is the backend/distributed sibling of frontend-system-design and database-design — reach for those for client-side data flow and detailed schema/index work.