software-architecture

Design the system the way a tech lead does: let the dominant quality attributes drive the structure, ahead of the technology you want to use or the cloud vendor's default. Name the constraints and the trade-offs out loud, then emit the artifacts (the diagrams a reader can navigate and the ADR the next person inherits) so the reasoning survives the meeting along with the result.

A design is a hypothesis under constraints. State the constraints, rank the attributes, sketch the smallest structure that satisfies them (on-premise or on a cloud), name what the structure costs, then emit the C4 diagrams and the ADR as the deliverables.

The depth bar across the eight steps is the design process. Cloud-specific moves live in cloud architecture; the two output formats are C4 diagrams and ADR and docs.

Steps

1. Frame requirements and constraints. Write the functional scope, the scale numbers (users, requests/sec, data volume, growth), and the hard constraints (budget, team size, deadline, compliance, data residency, existing stack). The frame holds once a back-of-envelope estimate of load and storage sits on the page; see capacity estimation.

2. Rank the quality attributes. From the eight attributes (scalability, availability, latency, consistency, security, cost, operability, evolvability), pick the two or three that dominate this system and state why. The ranking holds once each chosen attribute carries a target number or a concrete bar, not an adjective.

3. Sketch components and data. Draw the deployable units, each with one responsibility, and the data each one owns (entities, keys, access patterns), per components and data. The sketch holds once every container has one clear responsibility and the data model names its entities, keys, and access patterns.

4. Place it on infrastructure and define the contracts. Map each component to a building block, taking the build-vs-managed call, the region and availability-zone topology, and the network layout; for a cloud target, take a stance on each Well-Architected pillar. Then specify each contract: call style, payload shape, failure behavior. This step is done once every component names its building block and a reader can trace one end-to-end request across every boundary it crosses.

5. Analyze trade-offs against patterns. Per major choice, name the pattern and its alternative, then state what each option costs in the attributes ranked at step 2. The analysis holds once at least one viable alternative per major choice has a stated reason for rejection.

6. Check the failure modes. Test the design against the system-design failure modes and red flags and, for a cloud target, the cloud red flags: big design up front, resume-driven architecture, ignored NFRs, missing trade-off analysis, accidental distributed monolith, single-AZ production, click-ops. The check holds once each listed red flag is marked absent or recorded as an accepted risk with a named owner.