Web technical architecture: design a scalable base without oversizing the solution

An architecture is not judged by the number of services on its diagram. It's judged by the cost of a change, how it fails, and the team's ability to execute on it on a regular Monday morning.

1. Definition: architecture is the memory of constraints

Technical architecture organizes the components, data, interfaces, deployments and responsibilities necessary for a system to achieve its functional objectives and expected qualities: security, availability, performance, cost, operability, accessibility and scalability.

It does not consist of choosing a “stack”. Two applications using the same technologies can have radically different architectures depending on their boundaries, flows and failure modes.

A good decision always links four elements: observed constraint, considered options, accepted compromise and evidence allowing the choice to be re-examined. Without this trace, architecture becomes an expert opinion impossible to challenge.

2. Key figures: technology is becoming commonplace, arbitrages remain difficult

These surveys have population bias and do not dictate any individual choice. Above all, they show that a widely adopted technology does not become necessary for every workload.

3. The Register of Decisions: Nine Load-Bearing Choices

3.1. Decision 1 — What loss should the system prevent?

Start with the consequence, not the diagram. Loss of turnover, operational delay, disclosure, calculation error, inability to serve, supplier dependence or uncontrolled cost do not call for the same answers.

Define requirements in measurable form: path availability, 95e percentile response time, RPO/RTO, volume, croissance, data locality, deployment time, and cost cap. Classify mandatory, target and desirable.

Context register: requirement, measure, owner and consequence if the target is not achieved.

3.2. Decision 2 — Where to place functional boundaries?

Break down according to business responsibilities and pace of change, not according to technical layers only. A healthy boundary has clearly assigned vocabulary, rules and data. It often exists in a modular monolith before becoming a network service.

microservices are justified when truly independent teams, loads, risks, or cycles require separate deployment. They add latency, cross-service authentication, contracts, distributed consistency, observability and operations. We do not eliminate complexity; we move it within the network and the organization.

Border register: capabilities, ownership, dependencies, reasons for separation and conditions for future merger or extraction.

3.3. Decision 3 — Which data model carries the truth?

Choose the model according to the invariants and accesses. A relational basis is suitable for many transactional systems; a document, a time series, a search or a graph can complete when a constraint proves it.

Avoid a basis by technological mode before understanding consistency, backup and skills. Set source of truth, identifiers, quality, history, deletion, export and ownership. Caches speed up; they must not create an uncontrolled parallel truth.

Data trace: entities, invariants, transactions, volumetry, retention, access and migration strategy.

3.4. Decision 4 — Synchronous or asynchronous?

A synchronous call gives an immediate response and propagates the fault. A queue or an event decouples the rhythms, absorbs the peaks and makes recovery possible, at the cost of delayed coherence and additional operations.

Use asynchronous for long processing, fragiles integrations, notifications and flows capable of accepting a delay. Set idempotency, order, replay, poison queue, and state visibility. “Event-driven” without an event owner produces an archive of misunderstood messages.

Exchange trace: acceptable delay, failure behavior, number of attempts, deduplication and alerting.

3.5. Decision 5 — What rendering for the Web?

Static, server rendering, regeneration, rich client and edge represent trade-offs. Marketing or editorial content often benefits from early available HTML. An interactive application can load more client-side logic. The same product can combine several modes per route.

Evaluate SEO, performance, customization, cache, cost, invalidation and complexity. Google reminds that JavaScript applications go through crawling, rendering and indexing, and that server rendering or pre-rendering remains useful for users and robots (Google).

Render trace: page types, freshness, budget JavaScript, cache strategy and degraded mode.

3.6. Decision 6 — Buy, manage or operate yourself?

Each service is placed on a continuum: SaaS, PaaS, managed cloud service, container or managed infrastructure. The more we delegate, the more we reduce certain operations and the more we accept limits, variable costs and dependence.

Compare functional capacity, SLA, regions, security, export, quotas, skills, observability and cost at three years. A managed database can free a team from tasks without differentiating value. A critical proprietary feature can make an output costly.

Trace of supply: build/buy matrix, full cost, shared responsibilities and reversibility test.

3.7. Decision 7 — How does the system fail?

List dependencies and failure modes: timeout, slow response, error, data late, saturation, region unavailable, quota, certificate, DNS. Choose timeout, retry with backoff, circuit breaker, cache, queue, limitation or degraded mode depending on the context.

Retries without idempotence amplify a failure. Untested redundancy gives fictitious confidence. A supplier SLA does not guarantee the five-service journey.

Expected ADR: failure diagram, SLO, error budget, failover testing and recovery procedure.

3.8. Decision 8 — How to observe and change?

Observability connects metrics, logs and traces to questions: is the service successful, where is it slowing down, which version introduced the error? Define correlation identifiers, business events and protected data.

Delivery must produce small changes, reviewed, tested and reversible. Track change timing, frequency, deployment failure, and recovery time. DORA considers AI as an amplifier: a team without testing or feedback can generate more instability more quickly.

Expected ADR: signals by journey, retention, alerts, pipeline, rollout and rollback.

3.9. Decision 9 — When to reconsider the choice?

A decision has assumptions and thresholds. For example: “monolith as long as a team delivers the domain and the common deployment does not block more than x times per quarter”. Without a threshold, temporary choices become doctrine.

Organize a quarterly review of risks, costs, incidents and major changes. Don't reopen every preference every sprint; re-examine what assumptions have changed.

Expected ADR: date, revision signals, abandoned options and person authorized to decide.

4. ADR and decisions: a complete example before the diagram

Context dictates. The option responds. Compromise costs. The signal cuts. The date protects. The owner assumes. The test confirms.

For example, one team is considering separating the pricing engine from the rest of a monolith. The "microservice" option seems attractive because prices change often, but the survey shows a single team, a common deployment that doesn't block, transactions requiring immediate consistency, and no need for independent scaling.

The reasonable decision then is to create an internal modular boundary, with code API, contract testing, pricing version log, and clearly assigned ownership. Network service is deferred until a signal appears: independent team, incompatible release rate, distinct load, or demonstrated need for isolation.

The ADR keeps the rejected options and their reasons. This part matters as much as the choice, because a future architect will know if an option was forgotten, deemed too expensive or simply postponed. When the context changes, the discussion returns to facts instead of replaying a debate of preferences.

Short does not mean vague. A good record sometimes fits on one page, but it names the quantified constraints, the actors concerned, the risks accepted, the proof of validation and the condition of re-examination. A longer document is warranted when migration, compliance, or impact make the experience costly to reverse.

The register must remain alive. A quarterly review is often sufficient. Not all decisions need to be reopened, only those where an assumption, boundary, or owner has changed.

This discipline avoids two opposing trends: fixed architecture, where an old decision survives its constraints, and liquid architecture, where each newcomer replaces a technology before having measured the cost of change for teams, data, users and operations.

The result remains modest in appearance: a few pages, dated, linked to incidents and the backlog. Its value appears later, when oral memory is no longer sufficient.

5. Matrix of compromises: no architecture optimizes everything

6. Architectural review: testing five qualities before production

The Well-Architected frameworks of AWS and Microsoft converge on a multi-pillar reading. A useful review starts from the actual workload and produces decisions, not a decorative score.

6.1. Reliability

Critical journeys, dependencies, SLO, RPO/RTO, capacity, failover and recovery. Ask for proof of testing, not the presence of a “high availability” component.

6.2. Security

Identities, privileges, data, secrets, software chain, detection and incident. The NIST SSDF completes the review on secure development.

6.3. Performance

Frontend budgets, backend latency, requests, cache, volumetrics and load testing. Measure percentiles and field experience, not just server average.

6.4. Cost and sustainability

Cost per transaction or user, unused resources, storage, transfer, logs and commitments. Reducing unnecessary computation and data often improves cost and footprint simultaneously.

6.5. Operational excellence

Deployment, rollback, observability, alerts, runbooks, debt and liability. An architecture that only one person understands is not operable.

7. Deliverables expected from an architectural mission

• map of the business context, users and systems;
• prioritized functional and non-functional requirements;
• data models and trust flows;
• context, component, and deployment diagrams;
• ADR register with options and compromises;
• threat model and shared responsibilities;
• capacity, cost and availability scenario;
• delivery strategy, observability, backup and recovery;
• migration plan and rollback;
• risk reduction roadmap with proof of acceptance.

Diagrams are views, not the complete truth. They must be linked to code, infrastructure and decisions, then updated when a significant change occurs.

8. Cost and schedule: investing where the decision is difficult to reverse

The cost of a mission depends on criticality, number of systems, debt, unknowns, requirements and depth of prototypes. A few days are sometimes enough to make a targeted choice; several weeks are necessary for a platform, a migration or due diligence.

Marker Logiks: Spend more time on decisions that are hard to overturn—data model, boundaries, identity, central vendor, migration—and keep easily editable details in the backlog. A short technical tip can buy more information than a fifty page document.

The budget must include transfer and validation in production. An architecture “finished” before the first real data has not been proven.

9. Logiks Tips: Seven Questions That Deflate Overarchitecture

1. What measured stress does this component require?
2. Who will operate it at 3 morning hours or during holidays?
3. Which scenario becomes simpler, and which becomes more difficult?
4. Can we keep the boundary in the code before putting it on the network?
5. How to test for failure and recovery?
6. What is the cost per business unit, not just the monthly bill?
7. What signal will make us change our minds?

If no response is documented, defer the sophisticated choice.

10. Roadmap 30 / 60 / 90 days

10.1. Days 1 to 30 — Expose constraints

• map context, data, dependencies and incidents;
• prioritize non-functional requirements;
• measure current performance, cost and delivery;
• identify irreversible decisions and risks;
• create the ADR register.

10.2. Days 31 to 60 — Experiencing the options

• build tips on integration, load or migration;
• model breakdowns and costs;
• test backup, rollback and export;
• realize threat model;
• choose options and explain compromises.

10.3. Days 61 to 90 — Prove in production

• deliver a vertical path;
• instrument SLO, traces and business metrics;
• deploy gradually;
• perform a breakdown drill;
• revise ADRs based on observations.

11. FAQ

11.1. What is web architecture?

It is the organization of components, data, interfaces, deployments and responsibilities that allows the service to achieve its objectives and qualities. It includes both operating decisions and code.

11.2. Monolith or microservices?

The modular monolith is often suitable for a compact team and a changing domain. microservices are justified when team autonomy, load, risk or separate deployment produce a benefit greater than the distributed cost.

11.3. Should you use Kubernetes?

Kubernetes is widely adopted among container users in the CNCF corpus, but this adoption does not create a need. Choose it if multiple workloads and teams benefit from a common platform and the organization can leverage it.

11.4. How to make an architecture scalable?

First measure the load profile, then remove the bottlenecks: cache, indexes, queries, asynchronous processing, adapted statelessness and targeted scaling. Test peaks and degraded mode; don't replace a metric with a cloud promise.

11.5. How to avoid vendor lock-in?

Inventory proprietary functions, keep interfaces explicit, export data and configurations, estimate output cost and test critical elements. Avoiding any managed service may cost more than the risk; reversibility must be proportionate.

11.6. When to do an architectural review?

Before a difficult choice to reverse, a migration, a critical launch, a strong croissance or after repeated incidents. Repeat a light review when cost, risk, team or requirements change.

12. Conclusion

Technical architecture is not a collection of modern technologies. It is a discipline of compromise that transforms business constraints into verifiable and revisable decisions.

An evolving base does not provide everything. It protects invariants, keeps boundaries readable, facilitates small changes, and empowers the team to see, restore, and change minds.

13. Main sources

1. Eurostat — 53% of EU enterprises used paid cloud services in 2025, February 2026.
2. CNCF — Annual Cloud Native Survey 2025, January 2026.
3. CNCF — Full report of the investigation 2025, January 2026.
4. Microsoft — Azure Well-Architected Framework, 2026.
5. AWS — Well-Architected Framework pillars, accessed on July 13 2026.
6. Google SRE — Availability table, accessed on July 13 2026.
7. DORA — State of AI-assisted Software Development 2025, 2025.
8. HTTP Archive — Web Almanac 2025, Performance, published in 2026.
9. Google Search Central — JavaScript SEO basics, 2026.
10. NIST—Secure Software Development Framework 1.1, accessed on July 13 2026.