High-Level Design: [Solution name]

High-level design (HLD) for one solution: the level below the Solution Architecture Document and above the per-component low-level designs. It fixes the components and their responsibilities, the interfaces between them, the data flows, the deployment and environment view, how each non-functional requirement is allocated to components, and the security, resilience and operability design that every build team must follow. Views are organised with the concepts of ISO/IEC/IEEE 42010:2022 (stakeholders, concerns, viewpoints and views) and drawn in the style of the C4 model (context, container and deployment diagrams). Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Introduction and scope
2. Architecture drivers and SAD traceability
3. Stakeholders, concerns and views
4. System context
5. Logical architecture and components
6. Interfaces summary
7. Data architecture and data flows
8. Deployment and environments
9. NFR allocation and design tactics
10. Security design
11. Resilience, availability and recovery
12. Operability and observability
13. Transition, migration and rollout
14. Design decisions
15. Risks, assumptions and open issues
16. Traceability matrix
17. Design review checklist and LLD hand-off
18. Glossary and references

1. Introduction and scope

1.1 Purpose and audience

This document describes how [Solution name] is structured and deployed so that build teams can produce low-level designs and code without re-deciding the architecture, and so that security, operations and reviewers can check that the solution meets its non-functional requirements. Primary readers are the engineering leads of each component team, the platform and operations teams, the security architect and the architecture review board.

1.2 Scope

1.3 Position in the document set

1.4 Design summary

[Three to six sentences that a reviewer can read on their own.] Example: Order Hub is a set of four services behind an API gateway, deployed on a managed Kubernetes platform in two regions (active and warm standby). Orders are written to a managed relational database and published as events through a transactional outbox to a managed message broker, from which fulfilment, notification and analytics consumers read. Payment intent creation is a synchronous call, through the Payment orchestrator, to the payment service provider with a timeout set above the measured p99; the authorisation result returns asynchronously as an event. All service-to-service calls are authenticated with workload identities issued by the enterprise identity provider.

2. Architecture drivers and SAD traceability

2.1 Drivers

2.2 Constraints, assumptions and dependencies

3. Stakeholders, concerns and views

Diagram conventions: boxes are runtime containers or external systems, arrows show the direction of the request or event with its protocol, and dashed boundaries are trust or network zones. Every element in a diagram appears in a catalogue table with the same name.

4. System context

5. Logical architecture and components

5.1 Component catalogue

5.2 Responsibility rules

• Example: Only the Order service writes order state; every other component reads it through the API or the order events.
• Example: The Payment orchestrator is the only component that calls the payment provider; no other component holds provider credentials.
• Example: Adapters translate formats but hold no business rules.
• [Rule]

6. Interfaces summary

Integration rules that apply to every interface: [idempotency keys on all create operations], [correlation ID propagated end to end], [timeouts set below the caller's own deadline and above the provider's measured p99], [no inline retry where a retry would breach the caller's deadline], [no breaking change without a new major version and a deprecation period of N months, see API Deprecation Policy (architecture/api-deprecation-policy)].

7. Data architecture and data flows

7.1 Data stores

7.2 Data flows

7.3 Key flow: place order

Draw one sequence per journey that crosses three or more components or any external system. Example: the place-order flow below shows the synchronous payment step and the asynchronous event publication.

8. Deployment and environments

Infrastructure foundation: the solution is deployed into the landing zone described in Landing Zone Design (architecture/landing-zone-design) and Infrastructure Design (architecture/infrastructure-design); this section lists only what the solution adds.

9. NFR allocation and design tactics

Allocate budgets against the minimum acceptable value in the NFR Catalogue and design towards the target. Adding p95 values is conservative (the p95 of a sum is usually below the sum of the p95s), so a budget that fits by addition fits in practice. Example checks for Order Hub:

• Latency budget: 50 + 300 + 350 = 700 ms p95, which leaves 100 ms inside the 800 ms minimum. The 600 ms target is a design aim, verified in the first performance test.
• Timeout path: the Order service waits at most 450 ms for IF-005, so a request whose payment call times out returns its 503 within 50 + 300 + 450 = 800 ms, still inside the minimum. The Payment orchestrator's own timeout to the provider (400 ms) is below the 450 ms its caller allows, and its internal overhead is budgeted at 30 ms p95 (320 + 30 = 350 ms).
• Retries: one inline retry would take the worst case to 50 + 300 + 450 + 450 = 1,250 ms, so there is none on the request path. The client retries with the same idempotency key. With the timeout at the measured p99, about 1 % of intent calls are expected to time out; RSK-001 tracks this.
• Availability: unavailability adds approximately for serial dependencies: 0.01 + 0.02 + 0.02 + 0.01 + 0.03 = 0.09 %, so the product is about 99.91 %, inside the 99.9 % minimum but below the 99.95 % target. The broker is not in the product because the outbox decouples it (ADR-003), and the identity provider is not because token keys are cached for 10 minutes (LLD-002 section 12). Reaching the target needs a stronger provider SLA or a second provider; see ISS-002.

10. Security design

10.1 Trust boundaries and identity

10.2 Security controls by component

Threat model: [link to Threat Model (security/threat-model)]. Security reference architecture: [link to Security Architecture (security/security-architecture)].

11. Resilience, availability and recovery

Tiers use the T0 to T4 model of Resilience Tiering and HA/DR Design (architecture/resilience-tiering-ha-dr-design): Example values T1 RTO 1 h, RPO 5 min; T2 RTO 8 h, RPO 1 h; T3 RTO 72 h, RPO 24 h.

Detailed tiering and DR design: Resilience Tiering and HA/DR Design (architecture/resilience-tiering-ha-dr-design) and Disaster Recovery Plan (ops/disaster-recovery-plan).

12. Operability and observability

Full telemetry design: Observability Specification (ops/observability-spec). Handover to run teams: Operations Handover (ops/operations-handover).

13. Transition, migration and rollout

14. Design decisions

Full list and status history: Architecture Decision Log (architecture/architecture-decision-log). Record format: ADR (Full) (architecture/adr-full) or MADR (dev/madr).

15. Risks, assumptions and open issues

Programme-level items: RAID Log (project/raid-log).

16. Traceability matrix

Requirement-level traceability: Traceability Matrix (requirements/traceability-matrix).

17. Design review checklist and LLD hand-off

17.1 Review checklist

• Every component has one owner, one responsibility and an LLD ID.
• Every interface has a provider, a consumer, a contract reference, a security method and a versioning rule.
• Every Must NFR is allocated, and latency or availability budgets fit within the minimum acceptable value.
• Every synchronous call has a timeout above the provider's measured p99 and below the caller's deadline, and the timeout path still fits the minimum.
• Every store has an owner, a classification, a retention period and a backup method.
• Every external dependency has a failure row in section 11.
• Personal data flows and any cross-border transfer are listed.
• The deployment view matches the environments that will be tested.
• Decisions are in the log with status; no open issue blocks an LLD without a due date.

17.2 Hand-off to each low-level design

Each LLD must take, as fixed inputs: its component row from 5.1, the interfaces it provides and consumes from section 6, the NFR budgets allocated to it in section 9, the security controls assigned in 10.2, its tier and degraded mode from section 11 and the telemetry rules in section 12. If an LLD needs to change any of these, the change comes back to this HLD as a new version, not as a silent deviation.

18. Glossary and references

18.1 Glossary

18.2 References

Standard and licence note

Structure aligned with ISO/IEC/IEEE 42010:2022 (stakeholders, concerns, viewpoints and views in an architecture description) and drawing on the C4 model by Simon Brown (c4model.com, CC BY 4.0) for the context, container and deployment diagram style. Only concept names and clause topics are used; no text, definitions or tables are reproduced from ISO standards, and no C4 material is copied. This template is original text written for this collection. Check the current editions at iso.org and c4model.com, and obtain the standards for their normative requirements. Template licence: MIT.