A fact event records an entity’s complete state after an occurrence or change. Unlike a delta event, it carries every attribute, even when only one field changed. This pattern is also called a state event or Event-Carried State Transfer (ECST). section 6.2.2
Fact events suit publish-subscribe architectures because producers publish a comprehensive contract without knowing which attributes future consumers will need. Consumers implement event-specific logic independently, while the producer team maintains the consistent domain representation. section 6.2.2
The pattern provides several architectural benefits:
- Simplifies design and maintenance by presenting a complete entity state at a specific point in time. section 6.2.2
- Helps consumers recover current state by reading the latest event after missed messages or failures. section 6.2.2
- Decouples consumer logic from producer knowledge of downstream use cases. section 6.2.2
Profile update
A UserProfileUpdated event can include the user’s identity, contact details, addresses, social accounts, and phone number even when only the phone number changed. This gives each consumer a complete profile snapshot rather than a single-field instruction. section 6.2.2
Listing 6.1 UserProfileUpdated event carrying all the attributes from the user profile
{
"eventType": "UserProfileUpdated",
"eventId": "123e4567-e89b-12d3-a456-426614174003",
"timestamp": "2024-09-26T12:00:00Z",
"userProfile": {
"userId": "12345",
"name": "Alice Johnson",
"email": "alice.johnson@example.com",
"preferredLanguage": "en",
"addresses": [
{
"addressId": "98765",
"street": "456 Elm St",
"city": "Metropolis",
"state": "NY",
"zipCode": "10001"
}
],
"socialAccounts": [
{
"type": "twitter",
"handle": "@alicejohnson"
}
],
"phoneNumber": "+1-555-123-4567"
}
}
Inspect a complete UserProfileUpdated payload carrying all profile attributes. section 6.2.2
The choice depends on data behavior and storage. In a Customer 360 design, infrequently changing profiles and immutable transactions use fact events. Profile facts also pair naturally with compacted topics, which retain the latest state. section 6.2.7 section 6.3.5
Fact events require governance as adoption grows. Teams may begin with loosely defined JSON and optional fields, then introduce stronger schema validation and version control. A concrete design can use Avro schemas referenced from AsyncAPI specifications and stored in Git. section 6.2.7 section 6.3.5
Listing 6.7 Referencing an Avro schema from another file
asyncapi: 3.0.0
info:
title: Customer 360 Project
version: 1.0.0
description: >
This project aims to aggregate data from various sources, providing a
comprehensive view of customer information.
channels:
customerProfile:
description: Storing and distributing profile information of customers.
address: CUSTOMER_PROFILES
messages:
userProfile:
payload:
schemaFormat: 'application/vnd.apache.avro;version=1.9.0'
schema:
$ref: './path/to/submodule/path/to/UserProfile.avsc'
Review an AsyncAPI definition that references an external Avro schema for a customer profile event. section 6.3.5
