Architecture
System and API design, boundaries, trade-offs and architecture decision records.
Download all 91
- 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.
- Align architecture with team ownership
Matches system boundaries to team ownership using Conway's law and team topologies, finding split ownership and cognitive overload, and proposes changes to either.
- 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.
- Assess technical due diligence
Assesses a company's codebase and systems for an investor or acquirer, reporting architecture, scalability, security, licensing, team and cost risks with severity.
- Choose an API style
Chooses REST, GraphQL, gRPC or tRPC for an API from its clients, data shape, caching and team skills, and says what each choice will cost later.
- Choose how an app authenticates users
Chooses how an app handles user sign-in, covering sessions versus tokens, a hosted identity provider versus building it, passkeys, social login, MFA and refresh, for its clients and risk.
- Choose a CMS architecture
Chooses between a traditional, headless, hybrid or git-based CMS for a site or app, judging content model fit, preview, editor workflow, localisation and hosting.
- Choose consistency guarantees per operation
Decides, operation by operation, which consistency each read and write needs (strong, read-your-writes, monotonic, eventual) given replicas, caches and services, and how to deliver it.
- Choose a mobile platform approach
Chooses native, React Native, Flutter, Kotlin Multiplatform or a web app for a mobile product from team skills, UI needs, device APIs and long-term cost.
- 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.
- Choose a message broker
Chooses between Kafka, RabbitMQ, SQS and SNS, Pub/Sub, NATS or Redis Streams from ordering, replay, throughput, delivery guarantees and the team's operating capacity.
- Choose monorepo or multiple repositories
Decides between a monorepo and multiple repositories from team layout, release coupling, shared code, tooling and CI cost, with the setup each choice needs.
- Choose how services talk to each other
Decides for each interaction between services whether to use a synchronous call, an async command or a published event, with the coupling, latency and failure trade-offs of each.
- Choose a tech stack for a new product
Recommends a stack for a new product (language, framework, database, hosting) from requirements, team skills, hiring and time to market, favouring boring defaults.
- Choose a web rendering strategy
Chooses SSR, static generation, incremental regeneration, client rendering or streaming per route of a web app from SEO, data freshness, personalisation and hosting cost.
- Decide library, service or sidecar
Decides whether shared functionality should be a library, a service or a sidecar, weighing versioning, latency, failure modes, ownership and deploy coupling.
- Decide between microservices and a monolith
Decides whether a system should be a monolith, a modular monolith or microservices from team size, deploy pain, scaling and domain clarity, with the evidence that would change the answer.
- Decide whether to use event sourcing
Decides whether a domain should be event-sourced and, if so, specifies the event store, aggregates, snapshots, projections, event schema evolution and personal data handling.
- Decide on micro-frontends
Decides whether micro-frontends fit an organisation and, if so, the composition method, shared dependencies, routing and design system boundaries.
- Decide whether to rewrite or refactor
Decides whether to rewrite a struggling system or improve it in place, testing rewrite claims against risk and feature-freeze cost, and laying out an incremental path.
- Design an activity feed
Designs an activity feed or timeline, choosing fan-out on write, on read or a hybrid, with ranking, pagination, high-follower accounts and storage estimates.
- Design an anti-corruption layer
Designs a translation layer between your domain and a legacy system or third-party platform, with the model mapping, ownership of identifiers, error and gap handling, and how it shrinks over time.
- Design an API's collection query conventions
Designs one filtering, sorting, field selection and expansion convention for every list endpoint in an API, with a query syntax, allowed fields, cost limits and stable pagination.
- Design an authorization model
Chooses RBAC, ABAC or relationship-based authorization for a product, models resources, sharing and inheritance, and decides where checks are enforced and how they are tested.
- Design a backend for frontend
Decides whether web, mobile or partner clients need a backend-for-frontend or gateway layer, and designs its responsibilities, ownership, aggregation, caching, auth and what must stay out of it.
- Design bulk and async API operations
Designs batch and long-running API operations with async jobs, status polling or callbacks, partial failure reporting, size limits and safe retries.
- Design a chat system
Designs a chat or messaging feature with connection handling, message ordering, delivery and read receipts, history storage, presence and push fallback.
- Design a client SDK for an API
Designs a client SDK's public surface for an API, with auth, retries, pagination helpers, typed errors, versioning, and generated versus hand-written code.
- Design real-time collaborative editing
Designs real-time collaborative editing with CRDTs or operational transform, presence, persistence, offline merges and permission checks on every change.
- Design drafts and version history
Designs drafts, publishing, revision history, diffs and restore for user content such as documents, pages, product listings or configuration.
- Design CQRS read models
Designs separate read models (projections) for query-heavy screens or APIs, with what feeds them, how lag is surfaced to users, rebuilds, ordering and when plain queries are enough.
- Design custom domains for SaaS customers
Designs customer custom domains for a SaaS at scale, with DNS ownership verification, on-demand TLS certificates, routing to the right tenant, apex domains and failure handling.
- Design customer-facing analytics
Designs in-app dashboards and reports for customers, choosing read replicas, pre-aggregation, an OLAP store or embedded BI, with tenant isolation and freshness.
- Design a distributed lock or avoid one
Decides whether work across many instances needs a distributed lock and designs it with leases, fencing tokens and failure behaviour, or replaces it with a lock-free alternative.
- Design a distributed transaction with a saga
Designs a business operation that spans several services as a saga, with step order, compensations, the pivot step, orchestration or choreography, idempotency and stuck-saga recovery.
- Design DDD aggregates
Designs domain-driven design aggregates, entities and value objects inside one bounded context, with invariants, transaction boundaries and repository interfaces.
- Design enterprise SSO and user provisioning
Designs the enterprise identity offering of a B2B SaaS, with per-organisation SSO, SCIM provisioning and deprovisioning, group-to-role mapping, enforcement, admin self-setup and build or buy.
- 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 graceful degradation
Maps every dependency of a service or user journey, decides what users get when each one is slow or down, and specifies fallbacks, bulkheads, load shedding and the switches to trigger them.
- Design a GraphQL schema
Designs a GraphQL schema with types, nullability, connection pagination, mutations with payload errors, deprecation and an N+1-safe resolver plan.
- Design a gRPC service
Designs gRPC services and Protobuf messages with field numbering, evolution rules, streaming choice, deadlines, status codes and package layout.
- Design a high-throughput ingestion path
Designs an endpoint that takes in high volumes of events, telemetry or logs, with batching, buffering, partitioning, backpressure, validation and an explicit data loss guarantee.
- 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 an IoT device backend
Designs a backend for connected devices with provisioning, MQTT or HTTP ingestion, device shadow state, commands, firmware status and fleet-scale operations.
- Design a job scheduling system
Designs a scheduler for many delayed and recurring jobs (reminders, scheduled sends, per-tenant reports) with durable storage, fire-once claims, time zones, retries, overlap rules and scale limits.
- Design overload protection for a service
Designs how a service protects itself from overload, with concurrency limits, bounded queues, priority-based shedding, backpressure and client retry behaviour that does not make it worse.
- Design location-based search
Designs nearby and within-area search, choosing PostGIS, geohash keys or a search engine's geo queries, with ranking, filters, sharding by region and caching.
- Design a media processing pipeline
Designs image, video or document processing after upload with queues, workers, transcoding presets, status tracking, storage tiers and CDN delivery.
- Design a multi-region architecture
Decides between single region, active-passive and active-active for a system from latency, availability and residency needs, and specifies data replication, write routing, conflicts and failover.
- 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 multiplayer game backend
Designs a multiplayer game backend with accounts, matchmaking, dedicated or relayed session servers, authoritative state, persistence, region placement and live operations.
- Design a notification system
Designs a multi-channel notification backend with event triggers, user preferences, templates, batching and digests, dedupe, delivery tracking and retries.
- Design a B2B account and membership model
Designs the account model for a B2B SaaS with users, organisations, workspaces, memberships, invitations, ownership and billing, including users in several orgs and moving between them.
- 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.
- Design a serverless application
Designs an application on functions and managed services, with function boundaries, state, event triggers, platform limits, local testing, cost shape and when serverless stops fitting.
- Design service-to-service authentication
Designs how internal services authenticate and authorise each other with mTLS, signed tokens or workload identity, and how end-user context is propagated safely between them.
- Design tenant provisioning and offboarding
Designs automated tenant onboarding and offboarding for a SaaS, covering resources, schemas or databases, configuration, seed data, idempotent steps, retries, data export and verified teardown.
- Design a two-way data sync with another system
Designs two-way sync between your system and a CRM, ERP or other SaaS, with ID mapping, change detection, conflict rules, loop prevention and reconciliation.
- Design outbound webhook delivery
Designs the sending side of webhooks with event selection, signing, retries with backoff, ordering, endpoint disabling, replay and a delivery log customers can see.
- Design a long-running business process
Designs a long-running business process (onboarding, order fulfilment, approvals) on a durable workflow engine or on queues and cron, with timers, retries, human steps and versioning.
- 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.
- Estimate capacity for a new system
Turns usage assumptions for a proposed system into back-of-envelope peak requests per second, storage, bandwidth and instance counts, with the arithmetic shown.
- 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.
- Map service dependencies
Builds a dependency map of services, data stores and third parties from code, config and traces, flagging cycles, hidden coupling, critical paths and missing owners.
- 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.
- Find and remove single points of failure
Finds single points of failure in a system's components, data stores, third parties and people, and plans redundancy for each with its cost and a failover test.
- 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.
- Revisit an old architecture decision
Re-examines a past architecture decision or ADR against what has changed since, separates broken assumptions from mere discomfort, and recommends keep, amend or supersede with the cost of each.
- Run an event storming session
Runs a text-based event storming session that turns a business process into domain events, commands, actors, policies, read models and hotspots.
- Split a database shared by several services
Plans separating a database shared by several services into owned stores, with a table ownership map, replacements for cross-service reads and joins, and safe cutover steps.
- 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 a backend service's layers
Chooses layered, hexagonal or vertical-slice structure for a backend service and specifies the package layout, dependency rules, where transactions and validation live, and how tests map to it.
- Structure a desktop app
Designs an Electron or Tauri app's architecture with the process split, a typed IPC contract and its security, local storage, auto-update and background work.
- Structure a frontend app
Designs the architecture of a React, Vue, Svelte or Angular app with feature folders, a split of server cache and client state, data fetching, routing and dependency rules.
- 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.
- Structure a modular monolith
Structures a codebase as a modular monolith with module boundaries, a public interface per module, data ownership per module, in-process events, and dependency rules enforced by a check in CI.
- Support old mobile app versions
Designs how a backend keeps serving old mobile app versions, with version reporting, minimum version checks, soft and forced upgrades, compatibility windows and kill switches.
- Write architecture fitness functions
Turns architecture decisions and quality goals into automated fitness functions, such as dependency rules, latency budgets and coupling limits, that run in CI and fail when the design erodes.
- 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 architecture principles
Writes a short set of architecture principles for an engineering organisation, each with a rationale, implications and a test of when it applies, drawn from real decisions and incidents.
- 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.
- Write a sequence diagram
Draws a Mermaid or PlantUML sequence diagram of a request or process across services from code or a description, including async steps and error paths.
- Write a solution architecture proposal
Writes a client-facing solution architecture for a proposal or bid, with options, assumptions, components, integrations, risks, phasing and rough cost drivers.
Not: UI or visual design (design domain); refactoring existing structure (refactoring).