Architecture Fundamentals

A functional requirement says WHAT the system does ("users can reset a password"). A quality attribute says HOW WELL it does it — fast, available, secure, maintainable. Quality attributes shape the architecture; functions can usually be implemented in many architectures.

A decision is architecturally significant when it is expensive to change later, affects many parts of the system or many teams, and drives qualities such as performance, security or availability. Routine choices are local and cheap to reverse.

An architectural style is a named, whole-system shape — how the big pieces are split and how they talk (layered, event-driven, microservices). A design pattern is a small, local solution inside one piece (e.g. Strategy, Observer). Style = macro, pattern = micro.

The north-star is the agreed target architecture: a picture of the desired future state and why it is better. Current-state is what actually runs today. The gap between them drives a roadmap of incremental steps.

Architecture is the set of big, structural decisions about a system that are expensive or painful to change later — how it splits into parts, how those parts talk, and which technologies they use. Ordinary design decisions live inside one part and can be changed cheaply.

Instead of letting team structure dictate architecture, you change the team structure first so that the architecture you want becomes the natural one to build. Reorganize teams around the desired boundaries, then let Conway's Law do the work.

Reliability = how rarely it breaks. Availability = how much of the time it is usable. Availability ≈ MTBF / (MTBF + MTTR), so you can raise it either by failing less often or by recovering faster. "Three nines" = 99.9% ≈ 43 minutes down per month.

Rewrite it as a concrete scenario with numbers: who or what triggers it, under what conditions, what the system should do, and the measurable limit. E.g. "When traffic triples in 10 minutes, p99 latency stays under 800 ms with no dropped requests."

Look past feature lists for requirements that constrain structure: measurable quality goals (latency, uptime, scale, security), hard constraints (regulation, deadlines, existing systems), and the few features that touch everything. Turn vague wishes into testable scenarios, then prioritise by business value and technical difficulty.

Start from the two or three qualities that matter most — say, deployability and fault isolation, or simplicity and cost — rank them, and pick the style that scores highest on those while accepting its known weaknesses. Every style trades some qualities away; none wins everywhere.

Make and justify the hard-to-change decisions; define and continually re-check the technical boundaries and standards; make sure the built system actually matches them; understand the business domain and constraints; and communicate and mentor so that teams can make good local decisions themselves.

Ask: is it hard to undo, does it cross team or module boundaries, does it affect qualities like performance or security, and does it constrain future choices? If yes to any, it's significant — write it down as a short Architecture Decision Record: context, decision, consequences.

CAP: when the network splits a distributed system (a partition), you must choose between staying consistent (reject/block requests) or staying available (answer, possibly with stale data). PACELC adds: even with no partition, you still trade latency against consistency.

Classify decisions by how hard they are to undo. Hard-to-undo ones deserve analysis, prototypes, review and a written record. Easy-to-undo ones should be made quickly by the team and corrected from real feedback, because deliberating costs more than being wrong.

Choose event-driven when a producer should not wait for, or even know about, its consumers — bursty load, many independent reactions to one fact, long-running work. You pay with eventual consistency, harder debugging, duplicate and out-of-order messages, and error handling that is no longer a simple exception.

Build only what differentiates you from competitors; buy or use open source for everything else. Compare total cost over several years — not just licence versus salary — including integration, operations, upgrades, and the cost of switching or exiting later.

Requirements and technology change, so architecture decisions get made throughout a system's life, not once at the start. To stop reality drifting from intent, you enforce the important rules automatically in the build and pipeline instead of only writing them down.

Start from the business goals and constraints, translate them into concrete quality-attribute requirements (speed of change, cost per transaction, availability, market reach), and let those drive structural decisions — then check periodically that the architecture still serves the current strategy.

Delay a hard-to-reverse decision until the point where delaying further would eliminate an important option or start blocking work. Waiting buys information; waiting too long means the choice gets made by accident or by default.

In layered architecture, calls flow downward — UI depends on business logic, which depends on the database layer, so the domain ends up depending on infrastructure. In hexagonal, all dependencies point inward to the domain; the database and UI are interchangeable adapters plugged into interfaces (ports).

A technology radar is a periodically published list of tools, techniques, platforms and languages sorted into four rings: Adopt (default choice), Trial (use on a real project with a way to back out), Assess (worth an experiment or spike), and Hold (do not start anything new with it).

A team can only hold so much in its head. If it owns more systems and domains than it can understand, quality and speed drop. So you size each team's responsibilities to fit, and shrink their load by simplifying, delegating to a platform, or splitting the domain.

Team types: stream-aligned (owns a slice of business flow end-to-end), platform (provides self-service internal services), enabling (coaches others to gain skills), and complicated-subsystem (owns a part needing deep specialist knowledge). Interaction modes: collaboration, X-as-a-Service, and facilitating.

Latency is how long one request takes; throughput is how many complete per second. p99 (tail) is the slowest 1% — what unlucky users feel. Batching or queueing more work raises throughput but makes individual and tail latency worse.

A sensitivity point is a decision where changing it noticeably moves one quality attribute, such as response time. A trade-off point is a decision that moves two or more quality attributes in opposite directions, so you must consciously choose which one to favour.

CQRS splits the write side (commands that change state) from the read side (queries), letting each use its own model and store. It helps when reads and writes have very different shapes or volumes. It does not require event sourcing, and for ordinary CRUD it is pure overhead.

A golden path is a supported, opinionated default way to build and run a service — templates, libraries, pipeline, logging, deployment — so teams get the common work for free. You drive adoption by making it the easiest option, not by forbidding alternatives.

An architect's job is choosing between options, so knowing that many options exist and roughly what each costs is more useful than mastering one. Depth still matters — but it decays, and you can borrow depth from specialists; you can't borrow the knowledge that an option exists.

Look for team boundaries hiding inside the architecture: which teams must talk to ship one feature, who owns each database, and which services always release together. If the seams match old team or company boundaries rather than business capabilities, the org is the cause — fix ownership and data boundaries, not just the code.