---
title: "event-driven architecture | Skills We Assign For | Azendo"
description: "Event-driven architecture in production — what decoupling buys, what it costs in traceability, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/event-driven-architecture/"
---

[Skills](https://azendo.co/skills/) Architecture and patterns 

# event-driven architecture.

Event-driven architecture has components communicate by publishing and reacting to events rather than calling each other directly. Producers do not know their consumers, which makes adding behaviour cheap and makes reasoning about end-to-end flow substantially harder.

## Where event-driven architecture fits on a long engagement.

The appeal is genuine: a new consumer can react to an existing event without the producer changing at all, which makes extension cheap in a way request-response designs are not. For systems where many things must happen in response to one business event, it is the design that keeps those things from accumulating in one place.

The cost is that no single place describes what happens when an order is placed. Answering that question means tracing events across services, and without distributed tracing and a schema registry it becomes guesswork. Teams that adopt events without those two things usually find their debugging time grows faster than their delivery speed.

## What an assigned team does with event-driven architecture.

Event schemas are contracts with the same permanence as an API, and they are broken more casually because the consumer is not in the room. A schema registry and an explicit compatibility policy are what stop a producer change becoming somebody else's silent outage.

Operating that discipline is continuous rather than a setup task, and it needs the tracing to go with it. Where that is the constraint, the capacity is scoped alongside [devops managed services](https://azendo.co/services/cloud-and-devops/) rather than left to the application teams individually.

## What we use event-driven architecture for.

* One business event, many reactions New consumers added without touching the producer, so behaviour grows without one service accumulating all of it.
* Traceability across asynchronous flows Distributed tracing so a question about one order can be answered from data rather than from reading code.
* Schema compatibility as policy A registry and explicit rules, so a producer change cannot quietly break a consumer nobody remembered.

## How event-driven architecture capacity is assigned.

Event-driven work is assigned inside the disciplines that own the producing and consuming services, with the tracing and schema tooling scoped as part of it rather than assumed.

## Roles we assign event-driven architecture for

* [Software Architect Software development](https://azendo.co/services/software-development/software-architect/)

## Service lines it sits in

* [Software development](https://azendo.co/services/software-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in architecture and patterns

* [microservices and modular monoliths — skill we assign for](https://azendo.co/skills/microservices-and-modular-monoliths/)
* [AWS and Azure reference architectures — skill we assign for](https://azendo.co/skills/aws-and-azure-reference-architectures/)
* [Double-entry ledgers — skill we assign for](https://azendo.co/skills/double-entry-ledgers/)
* [Multi-tenant architecture — skill we assign for](https://azendo.co/skills/multi-tenant-architecture/)
* [CQRS — skill we assign for](https://azendo.co/skills/cqrs/)
* [Domain-driven design — skill we assign for](https://azendo.co/skills/domain-driven-design/)

## Tell us what your roadmap needs event-driven architecture for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)