# Patterns & Best Practices in Event-Driven Systems

DevFeed: [Patterns & Best Practices in Event-Driven Systems](<https://devfeed.tech/articles/patterns-best-practices-in-event-driven-systems-30800.md>)

Original publisher: [Read original article](<https://devblog.kogan.com/blog/patterns-amp-best-practices-in-event-driven-systems>)

Author: Victor Wenas

Published: 2025-12-08T06:14:51Z

Content type: tutorial

Language: en

Sources: [Kogan.com](<https://devfeed.tech/sources/kogan-com.md>)

Topics: [event driven](<https://devfeed.tech/topics/event-driven.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Publish-subscribe pattern](<https://devfeed.tech/topics/pubsub.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [architecture-pattern](<https://devfeed.tech/tags/architecture-pattern.md>), [decoupling](<https://devfeed.tech/tags/decoupling.md>), [event-driven](<https://devfeed.tech/tags/event-driven.md>), [event-sourcing](<https://devfeed.tech/tags/event-sourcing.md>), [latency](<https://devfeed.tech/tags/latency.md>), [patterns](<https://devfeed.tech/tags/patterns.md>), [systems](<https://devfeed.tech/tags/systems.md>)

## AI overview

This tutorial explains three event-driven architecture patterns: event notification, Event-Carried State Transfer, and Event Sourcing. It describes their trade-offs, including service coupling, additional data fetches, payload size, schema management, resilience, and latency.

## Source excerpt

Designing Robust, Scalable, Maintainable Event Architectures Event-driven architecture (EDA) gives teams the ability to build decoupled, scalable systems that evolve independently. In the previous article, we introduced the idea using a restaurant analogy: instead of shouting instructions across the kitchen, teams place "dockets" on the rail and stations take what they need. We'll continue that analogy lightly in this post--sprinkling it here and there--while focusing on the engineering patterns that make event-driven systems work in practice. Core Patterns in Event-Driven ArchitecturePattern 1: Event Notification An event notification is a tiny message that simply declares "something happened." It doesn't contain all the details--just enough for downstream systems to react. Think of it like a kitchen bell dinging: The bell doesn't contain the meal. It's just a signal. The cook still needs to check the ticket rail (the database) for the details of the order 12345. Example { "eventName": "OrderCreated", "orderId": 12345, "createdAt": "2025-11-26T01:00:00Z" } Why it's useful Extremely lightweight Easy to publish, easy to fan out Consumers decide how much extra data they need Trade-offs Consumers must fetch details themselves More cross-service calls -> more coupling Higher latency when many consumers query upstream systems Use this pattern when the event is a simple trigger--like a bell, not a full meal. Pattern 2: Event-Carried State Transfer (ECST) In Event-Carried State Transfer, the event carries all required data so consumers don't need to make additional calls. It's the equivalent of the chef not only ringing the bell but also placing the complete plated dish on the pass. No one needs to ask questions--everything needed is right there. { "eventName": "OrderPacked", "orderId": 12345, "items": [ { "sku": "ABC123", "qty": 2 } ], "warehouseId": 19, "totalWeightGrams": 1850 } Why it's powerful Zero need for back-calls -> full decoupling Highly resilient--consumers can proces