# event-sourcing Published articles for event-sourcing. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Event-Driven Architecture with Apache Kafka DevFeed: [Event-Driven Architecture with Apache Kafka]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-03-16T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [event driven](), [Kafka](), [Apache-Kafka](), [Scalability](), [Resilience](), [streaming-data-processing](), [Latency](), [systems]() Tags: [apache-kafka](), [architecture](), [asynchronous](), [consumer](), [distributed-systems](), [event-driven-architecture](), [event-sourcing](), [kafka](), [microservices](), [partitions](), [real-time](), [resilience](), [scalability](), [schemas](), [stream-processing]() ### AI overview This tutorial explains event-driven architecture and how Apache Kafka supports asynchronous, real-time data processing. It covers producers, consumers, immutable events, event sourcing, scalability, resilience, stream-processing pipelines, and challenges such as ordering, debugging, and eventual consistency. ### Source excerpt Event-driven architecture replaces synchronous point-to-point calls with immutable events on a durable log, so producers and consumers scale and fail independently. Kafka provides that log: topics sharded into ordered append-only partitions, replicated across brokers, with consumer groups sharing partitions to scale read throughput. ## Refining SQL Data Models Without Breaking Legacy Code DevFeed: [Refining SQL Data Models Without Breaking Legacy Code]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-01-20T17:49:07Z Content type: article Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [SQL](), [Databases](), [legacy]() Tags: [database](), [event-sourcing](), [legacy-code](), [sql](), [sql-database]() ### AI overview This article explains how refinement mappings can support SQL schema changes while preserving compatibility with existing code. It applies the approach to migrating a boolean column to a timestamp, then to an event-sourcing-like model, and examines how mutability constraints affect whether the refinement remains valid. ### Source excerpt Imagine we have a SQL database with a user table, and users have a non-nullable is_activated boolean column. Having read That Boolean Should Probably Be Something else, you decide to migrate it to a nullable activated_at column. You can change any of the SQL queries that read/update the user table but not any of the code that uses the results of these queries. Can we make this change in a way that preserves all external properties? Yes. If an update would set is_activated to true, instead set it to the current date. Now define the refinement mapping that takes a new_user and returns an old_user. All columns will be unchanged except is_activated, which will be f(new_user).is_activated = if new_user.activated_at == NULL then FALSE else TRUE Now new code can use new_user directly while legacy code can use f(new_user) instead, which will behave indistinguishably from the old_user. A little more time passes and you decide to switch to an event sourcing-like model. So instead of an activated_at column, you have a user_events table, where every record is (user_id, timestamp, event). So adding an activate event will activate the user, adding a deactivate event will deactivate the user. Once again, we can update the queries but not any of the code that uses the results of these queries. Can we make a change that preserves all external properties? Yes. If an update would change is_activated, instead have it add an appropriate record to the event table. Now, define the refinement mapping that takes newer_user and returns new_user. The activated_at field will be computed like this: g(newer_user).activated_at = # last_activated_event let lae = newer_user.events .filter(event = "activate" | "deactivate") .last, in if lae.event == "activate" then lae.timestamp else NULL Now new code can use newer_user directly while old code can use g(newer_user) and the really old code can use f(g(newer_user)). Mutability constraints I said "these preserve all external properties" and that was a ## Patterns & Best Practices in Event-Driven Systems DevFeed: [Patterns & Best Practices in Event-Driven Systems]() Original publisher: [Read original article]() Author: Victor Wenas Published: 2025-12-08T06:14:51Z Content type: tutorial Language: en Sources: [Kogan.com]() Topics: [event driven](), [systems](), [Publish-subscribe pattern]() Tags: [architecture](), [architecture-pattern](), [decoupling](), [event-driven](), [event-sourcing](), [latency](), [patterns](), [systems]() ### 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 ## Designing a Cloud-Native Event Log Beyond Kafka's Partition Model DevFeed: [Designing a Cloud-Native Event Log Beyond Kafka's Partition Model]() Original publisher: [Read original article]() Published: 2025-04-24T14:25:00Z Content type: opinion Language: en Sources: [Gunnar Morling]() Topics: [Kafka](), [Amazon S3](), [cloud-infrastructure](), [event driven](), [systems]() Tags: [agentic](), [cloud-native](), [event-driven](), [event-sourcing](), [kafka](), [partition](), [pipelines](), [s3]() ### AI overview The article proposes a personal wishlist for a durable cloud-native event log designed beyond Kafka's traditional architecture. It discusses separating storage and compute, using object storage such as S3, removing partitions, and providing key-centric streams with ordering and dynamically scalable consumers. ### Source excerpt The last few days I spent some time digging into the recently announced KIP-1150 ("Diskless Kafka"), as well AutoMQ's Kafka fork, tightly integrating Apache Kafka and object storage, such as S3. Following the example set by WarpStream, these projects aim to substantially improve the experience of using Kafka in cloud environments, providing better elasticity, drastically reducing cost, and paving the way towards native lakehouse integration. This got me thinking, if we were to start all over and develop a durable cloud-native event log from scratch--Kafka.next if you will--which traits and characteristics would be desirable for this to have? Separating storage and compute and object store support would be table stakes, but what else should be there? Having used Kafka for many years for building event-driven applications as well as for running realtime ETL and change data capture pipelines, here's my personal wishlist: ## Take Part in TDD February 2025 DevFeed: [Take Part in TDD February 2025]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-01-31T21:35:50Z Content type: tutorial Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [Development](), [test]() Tags: [2025](), [development](), [event-sourcing](), [tdd](), [test](), [tests]() ### AI overview An invitation to participate in TDD February 2025 through the Transport Tycoon DDD/ES Kata. The article suggests exercises for leaders, engineers, and advanced participants, including writing acceptance criteria, solving tasks with and without TDD, developing incrementally, and sharing results. ### Source excerpt The future belongs to those who prepare for it today. ## Event sourcing with Kafka: A practical example DevFeed: [Event sourcing with Kafka: A practical example]() Original publisher: [Read original article]() Author: Joe Karlsson Published: 2023-09-27T00:00:00Z Content type: tutorial Language: en Sources: [Tinybird]() Topics: [Kafka]() Tags: [event-sourcing](), [how-to](), [i-built-this](), [implement](), [kafka]() ### AI overview A practical example of implementing event sourcing with Kafka, describing how it creates an immutable history and addressing implementation complexity. ### Source excerpt Event sourcing with Kafka creates an immutable history of everything. Here's how to implement it without the usual complexity. ## Replaying events using AWS S3 DevFeed: [Replaying events using AWS S3]() Original publisher: [Read original article]() Author: Marko Savic Published: 2022-04-08T08:40:24Z Content type: tutorial Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [Amazon S3](), [event driven](), [Microservices](), [Amazon Web Services](), [AWS CloudFormation](), [Serverless]() Tags: [aws](), [aws-lambda](), [aws-s3](), [cloudformation](), [debugging](), [event-driven](), [event-sourcing](), [lambda](), [microservices](), [s3](), [serverless](), [sns](), [software-architecture](), [versioning]() ### AI overview This tutorial describes replaying failed events in serverless, event-driven microservices by storing AWS Step Functions events in versioned Amazon S3 objects. It also outlines using a dead-letter queue and Lambda to retrieve the latest event and trigger the workflow again. ### Source excerpt In the world of event-driven microservices one of the important tasks is to have a mechanism to recover from failed events, as well as to have possibility to replay certain events. We at Homegate deal with serverless microservices. If, at any of these services, we encounter a failure during processing of an resource, we might need to recreate the last event or series of events for given resource. Usecase The central part of ingestion process is AWS StepFunctions that lives in a, so called, importer service. It is responsible for various enrichments and conditional actions on resource. The last step of the step function is sending an event to the AWS SNS which is consumed by many downstream services as you can see in the following diagram. Step functions as central part of ingestion process Here, many open questions can be identified: How to deal with failure within AWS StepFunctions? How to recreate SNS event if needed for downstream system? Would it be possible to replay the whole step function? Solution Possible answer to these questions would be to store events that goes through AWS StepFunctions into some kind of event storage, in Homegate case, we chose AWS S3. In order to support the whole history of events for given resource, S3 bucket versioning is used. This is quite handy for replaying series of events or even for debugging purposes. Here is a sample CloudFormation which enables that functionality: EventLogBucket: Type: 'AWS::S3::Bucket' Properties: BucketName: 'sample-unnique-bucket-name' AccessControl: Private PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: service Value: sample-service - Key: env Value: !FindInMap [ Stages, !Ref Stage , Env ] VersioningConfiguration: Status: Enabled That way we can replay the whole step functions flow using last logged event for given resource. That functionality could be available from different places, like DLQ or via api end