Conceptual
Login

About Solutions Architecture: From Requirements to a Design You Can Defend

Copied

How do you get from a page of requirements to a system design you can defend in a review? Solutions architecture is the discipline of making that trip on purpose: turning vague quality goals—fast, reliable, scalable, secure, affordable—into measurable scenarios, decomposing the system into components with clear contracts, choosing the tactic that buys each quality attribute, and writing down the trade-off so the next person understands why. This path walks that sequence. You will learn to write a quality attribute scenario with a stimulus, a response and a number; to separate a constraint from a requirement; to decide where a synchronous call ends and a queue begins; to reason about availability, scalability, latency and consistency with the arithmetic behind each rather than the vendor's slogan; and to record an architecture decision so that it can be revisited when its assumptions expire. The design examples use cloud building blocks—load balancers, caches, standby databases, queues—because that is where most systems are built today, but every Concept is vendor-neutral and holds on any platform. You need to have built or run at least one web service with a database. No certification is assumed or targeted.

Estimated Time to Complete

Only available after login

What You'll Learn

Concepts:
A Quality Goal Without a Number and a Condition Is a Wish, Not a Requirement Microservices Architecture Building, Buying, and Renting a Capability Differ in Which Work Stays Yours A Fitness Function Turns an Attribute Goal Into a Check That Runs Without You Waiting Time Rises Without Bound as Utilization Approaches One, So Headroom Is the Design Target A Boundary Is Only Real If Its Contract Is Written Down Load Is Three Numbers: the Average, the Peak, and the Rate at Which Both Grow An Architecture Decision Record States the Options You Rejected and Why Two Components Sharing One Database Are One Component With Two Names Retry with Exponential Backoff Eventual Consistency Every Tactic You Add Buys One Quality Attribute by Spending Another Circuit Breaker Pattern Serving From a Second Geographic Area Buys One Requirement and Charges You Consistency and Cost Your Availability Is the Product of Everything a Request Must Touch A Requirement Says What the System Must Do; a Quality Attribute Says How Well It Must Do It A Timeout Is Chosen From the Latency Distribution, and Too Short Turns Slow Into Failed Rolling, Blue-Green and Canary Answer One Question: How Fast Can You Take It Back An Indicator Is Measured, an Objective Is Chosen, and an Agreement Carries a Penalty Every Assumption You Design On Needs a Written Expiry Date Synchronous vs Asynchronous Service Communication Stateless Service Design A Failure Domain Is What One Failure Stops, and Blast Radius Is How Much of Your Design Sits in One The Right Design Is the Simplest One That Passes Every Scenario You Wrote Monolith-First Strategy Idempotency API Versioning Bulkhead Pattern A Quality Attribute Scenario Names Its Source, Stimulus, Environment, Artifact, Response and Measure A Constraint Is a Decision Already Made For You; a Requirement Is One You Still Get to Make Cost Is a Quality Attribute With a Target, and It Trades Against Every Other One A Design Drifts From Its Diagram Unless a Review Has Both a Cadence and a Trigger A Partition Is the Unit of Both Ordering and Parallelism CAP Theorem Cost per Finished Result Versus Advertised Price per Hour Little's Law Ties Throughput, Concurrency and Latency Together A Cache Is a Second, Older Copy, So Caching Anything Is Agreeing to Be Wrong for a While Redundancy Copies Your Mistaken Delete Within a Second; Only a Backup Undoes It A Decision You Cannot Undo Deserves More Analysis Than One You Can An Incident Is Only Paid For When Its Finding Becomes a Written Requirement or a Test Encryption at Rest Rate Limiting Coupling and Cohesion State How Much Data You May Lose and How Long You May Be Down, in Minutes, Before You Need To Every Piece of Data Has Exactly One Owner That May Write It Quality Attributes Contradict Each Other, So Rank Them Before You Design Anything Event-Driven Architecture A Capacity Plan Sizes for Peak Plus Growth at a Target Utilisation, Not for Average Load Sensitivity Analysis Finds the Single Number That Would Flip Your Decision Writing Down What the System Will Not Do Is Half of Saying What It Will Dependencies Must Point One Way, and a Cycle Is a Design Defect Horizontal Scaling Replace a System One Capability at a Time Behind a Facade Until Nothing Reaches the Old One Least Privilege Principle Bounded Context Being Able to Explain a Failure Is a Property You Design In, Not One You Add Afterwards Walk a Candidate Design Through Each Scenario Before You Trust It Rollback Is Something You Decide Is Possible Before You Deploy Build the Smallest Thing That Answers the Riskiest Unknown First Technical Debt and Self-Admitted Technical Debt in Software Engineering Message Queue Availability Needs Redundancy, Detection and Failover, and Missing Any One Buys Nothing The Distance Between Your Objective and Perfection Is a Budget You Are Allowed to Spend A User's Deadline Is One Budget Divided Among the Hops, Not a Timeout Repeated at Each One A Replacement Is Not Finished Until the Old Component Has No Callers and Is Switched Off Availability from MTBF and Mean Time to Repair

What you will learn

No introduction video available

About Chief Galen Tyrol

C

Guide profile coming soon.