Projects / Architecture · Automotive

Volvo CQRS Framework

Designed a cloud-agnostic CQRS/event-sourcing platform that helped Volvo’s autonomous vehicle data stay consistent across providers and teams.

40% faster team velocityAzure · AWS · GCP

Overview

This engagement focused on a cloud-agnostic CQRS and event-sourcing framework for Volvo’s next-generation autonomous vehicle management work.

The project needed more than a set of services. It needed a shared architecture that a large distributed team could build on without every squad inventing its own patterns for commands, queries, events, audit history, and cloud integration.

Client: Infosys / Volvo project
Industry: Automotive technology
Duration: 2 years
Role: Principal Developer
Team: 22 developers, including 9 senior-level engineers

Built for

  • Distributed engineering teams working across bounded domains.
  • Systems that need auditability and replayable state changes.
  • Cloud strategies that cannot lock the product to one provider.
  • Autonomous vehicle management workflows where correctness and traceability matter.

What made it hard

Architecture at this scale fails when every team interprets the pattern differently.

CQRS and event sourcing can be powerful, but they can also become ceremony if the domain boundaries are weak or the event model is unclear. The challenge was to make the architecture useful for daily development, not just correct on a diagram.

What I built

Domain-driven architecture

Helped define bounded contexts, domain models, and service boundaries so teams could work independently without breaking the larger system.

CQRS framework

Separated command and query paths so write-side validation, read-side performance, and scaling needs could be handled cleanly.

Event-sourcing foundation

Implemented replayable event history for traceability, debugging, audit needs, and state reconstruction.

Cloud-agnostic abstractions

Designed abstractions around cloud services so the same architectural model could be deployed across Azure, AWS, and GCP.

Team enablement

Supported senior developers, documentation, architecture discussions, and executive-level technical presentations.

Why I built it this way

Large teams do not need more cleverness. They need shared patterns that reduce coordination cost.

The goal was not to make every service academically pure. The goal was to give engineers a reliable way to model behavior, move data, audit changes, and deploy across cloud environments without fighting the architecture every sprint.

CQRS and event sourcing made sense because the system needed clear intent, traceable history, and scalable read paths. The cloud-agnostic layer made sense because deployment flexibility was a real requirement, not a theoretical preference.

Impact

  • 40% faster feature delivery through shared patterns and reusable architecture.
  • Cloud flexibility across Azure, AWS, and GCP.
  • Complete audit history through event sourcing.
  • Better team consistency across a 22-person distributed group.
  • Executive-ready architecture story for stakeholders evaluating the platform.

More projects