Architecture
System and API design, boundaries, trade-offs and architecture decision records.
Download all 23
- Compare design options
Compares two to four technical options against the criteria that matter, weighs reversibility and risk, and recommends one. Use when a team is stuck choosing between approaches or tools.
- Design an API contract
Designs an API contract before implementation, with operations, schemas, errors, pagination, idempotency and evolution rules. Use when adding an API that other teams or clients will call.
- Review a system design
Reviews a design document or proposal for failure modes, scaling limits, data and consistency risks and operability gaps, and returns ranked findings. Use before a design review or before building.
- Software architect
Acts as a pragmatic software architect who designs from requirements and constraints, names trade-offs and failure modes, and keeps designs as simple as the problem allows.
- Write an architecture decision record
Writes an architecture decision record that states one decision, the forces behind it, the options weighed and the honest consequences. Use when a significant technical choice is made or proposed.
- Write an engineering design doc
Writes an engineering design doc or RFC with context, goals and non-goals, options and trade-offs, the decision, risks and a rollout plan. Use before building a change that needs review or buy-in.
- API design track
Takes a new API from consumer needs to a resource model, a reviewed contract, error and versioning rules, and a mock with contract tests, pausing for approval between steps.
- API designer
Acts as an API designer who shapes REST, GraphQL and RPC contracts from consumer needs, keeps naming, errors and pagination consistent, and evolves published APIs without breaking clients.
- Choose a game entity architecture
Decides between inheritance, component composition and an entity component system for a game from entity counts, team and engine, with data layout, update order and switching cost.
- Design an event-driven system
Designs an event-driven flow with event schemas, topics, partition keys, idempotent consumers, an outbox, retries, dead letters and replay. Use when moving synchronous calls onto a broker.
- Design a firmware task architecture
Designs firmware structure, choosing a superloop, cooperative scheduler or RTOS, with priorities, stack sizes, inter-task communication, layering and how deadlines are met and checked.
- Design an internal developer platform
Designs an internal developer platform from real developer pain points, with capabilities, build versus buy, the thinnest viable platform first and adoption measures. Use before building one.
- Design a multi-tenant architecture
Chooses a silo, pool or bridge tenancy model for a SaaS product and specifies data isolation, tenant routing, noisy-neighbour limits, per-tenant config and the migration path.
- Design a plugin system
Designs a plugin or extension system for an application, with extension points, a stable versioned API, discovery and loading, isolation and permissions, and a policy for breaking changes.
- Estimate cloud costs for an architecture
Estimates the monthly cloud cost of a proposed architecture from usage assumptions, with a line-item breakdown, scale scenarios and cost risks. Use before committing to a design or a budget.
- Find bounded contexts and service boundaries
Maps a domain into bounded contexts from its language, data ownership and change patterns, and proposes module or service boundaries that minimise cross-boundary calls, with how they communicate.
- Plan scaling a service
Finds what limits a service's capacity from load and resource data, then plans scaling in phases, cheapest fixes first, with the capacity each phase buys. Use before growth outruns the system.
- Review an API's design for consistency
Reviews an existing or proposed API endpoint by endpoint for consistent names, errors, pagination, versioning and backward compatibility, with a recommended change and rationale for each issue.
- Review an existing codebase's architecture
Reviews the architecture of an existing codebase from its real dependencies, finding coupling, weak cohesion, layering violations and scaling limits, and proposes ranked, incremental changes.
- Staff engineer
Acts as a staff engineer who scopes ambiguous cross-team problems, writes the doc that unblocks a decision, weighs organisational cost with technical cost and grows other engineers.
- Structure mobile app modules
Designs the module architecture of a growing mobile app, covering presentation pattern, feature modules, dependency rules, navigation, design system and build times, with a migration path.
- Write an architecture overview document
Writes an architecture overview of an existing system from its code and notes, covering context, components, boundaries, key decisions and trade-offs, with diagrams and short decision records.
- Write C4 architecture diagrams
Produces C4 context, container and optionally component diagrams as Mermaid, PlantUML or Structurizr DSL from a codebase or description, with a legend and stated assumptions.
Not: UI or visual design (design domain); refactoring existing structure (refactoring).