Highly available multi-AZ web platform for Volkswagen Group

Context

For Volkswagen Group’s GENWIN Web Platform and SA Platform (Inventiv IT, 2025 – 2026, Paris) I handled the architecture and deployment of a highly available web platform on multi-AZ AWS infrastructure defined as code. I designed the application with Clean Architecture, guided the teams on TDD, quality and CI/CD, and contributed functional scoping, architecture documentation (the DAT) and Agile sprint follow-up with business teams.

Problem

A web platform used by business teams cannot afford to go down when a single component fails. Availability has to be designed in at the infrastructure level, and it has to stay reproducible: an environment that cannot be rebuilt from code drifts over time, and drift is a common cause of outages.

Architecture decisions

A multi-AZ architecture for availability

The platform is designed as a multi-AZ high-availability architecture on AWS, spreading the application across several availability zones so that the loss of one zone does not take the platform down. The architecture ensures 99.9% availability.

Trade-off: running in more than one zone costs more and adds design work on state, load distribution and failover. In exchange the platform tolerates a zone-level failure.

Infrastructure as code

The infrastructure is defined as code (IaC), so every environment can be reviewed, versioned and recreated on demand.

Trade-off: infrastructure as code requires discipline. Manual changes in the console create drift, so the code has to be the only path to change.

Clean Architecture for the application

The application follows Clean Architecture: business rules sit at the centre and do not depend on frameworks or infrastructure.

Trade-off: there are more layers and boundaries than in a simple layered application. The payoff is testability and the freedom to change frameworks or infrastructure without rewriting business logic.

Engineering practices: TDD, quality and CI/CD

I guided the teams on TDD, quality and CI/CD, so that the reliability designed into the infrastructure is matched by reliability in the code and in its delivery.

Trade-off: coaching takes time from feature work in the short term. It pays back through fewer regressions and safer releases.

Documentation and delivery

Functional scoping, architecture documentation (the DAT) and Agile sprint follow-up with business teams kept decisions written down and aligned with what the business needed.

Trade-off: documentation is only useful while it is current. A concise DAT maintained next to the work is worth more than a long one that goes stale.

Outcome

The platform runs on a multi-AZ AWS architecture that ensures 99.9% availability, defined as code and documented in a DAT, with the teams working through TDD and CI/CD practices.