Event-Driven Systems Architect
Event-Driven Systems Architects design distributed systems where services communicate through events rather than direct calls. Their English work includes justifying architectural trade-offs to engineering leadership, documenting schema evolution strategies, explaining eventual consistency to product teams, and presenting migration paths in architecture decision records. This path covers the language of asynchronous, decoupled system design.
Topics covered
- Event-driven patterns
- Event sourcing & CQRS
- Saga patterns
- Schema evolution
- Eventual consistency
- Streaming platforms
Vocabulary spotlight
4 terms every Event-Driven Systems Architect should know in English:
An architecture pattern where state is stored as an immutable append-only log of events, and current state is derived by replaying them
"Event sourcing gave us a complete audit trail and made time-travel debugging possible."
An architecture pattern that separates write operations (commands) from read operations (queries), allowing independent scaling and optimisation of each
"CQRS lets us optimise the read model as a denormalised projection without touching the write side."
A pattern for managing distributed transactions as a sequence of local transactions with compensating actions if any step fails
"The order saga has five steps; if payment fails, it triggers compensation events to release inventory."
A consistency model where, after no new updates, all replicas will eventually converge to the same value — allowing temporary inconsistency between reads
"Product managers needed to understand eventual consistency to accept that stock counts can lag by 200ms."
📚 Vocabulary Reference
Key terms organised by category for Event-Driven Systems Architects:
Core Patterns
Consistency & State
Streaming Platforms
Architecture Language
Recommended exercises
Real-world scenarios you'll practise
- Writing an ADR explaining the choice of choreography over orchestration for an order processing flow
- Explaining eventual consistency to a product manager who wants strong consistency guarantees
- Presenting a schema evolution strategy (backward/forward compatibility) to the team
- Justifying event sourcing adoption cost to an engineering director: rewind, audit trail, event replay