Twitter

Blog

Company Website

Event Sourcing is a useful way to think about software design. You're here, so I'm guessing you already believe this. But why?
Event Sourcing corresponds to a useful way to think about reality, from science to relationships.
After this keynote, you'll have new ways to explain why Event Sourcing is so important in software, and new ways to leverage this thinking in real life.

Keynote: EventSourcing & Reality

What happens if you mix Event Storming with a Low Code Platform? Christof, Alex and Cody will take you on a visual modeling journey based on a real use case from a client's project.

From Event Storming to working code

LinkedIn

CQRS and especially Event Sourcing are often surrounded by an air of mystery. While for some, the associated fear, uncertainty, and doubt prevent them from venturing further. For others, the endless promises make it an irresistible source of magic pixie dust. The reality, however, lays somewhere in between.

In this session, Allard will take a pragmatic approach to CQRS and Event Sourcing. We'll briefly recap what they are and how they can be used to pragmatically implement a Microservices architecture. But also if you're just looking for building a structured monolith, these architectural patterns are your friends. In fact, you can dynamically switch between monolith and microservices.

Finally, we'll put the code where the talk is. Allard will show how promises are made reality, using Axon Framework and Axon Server.

CQRS and Event Sourcing without the pixie dust

Yet another presentation about Event Sourcing? Yes and no. Event Sourcing is a really great concept. Some could say it’s a Holy Grail of the software architecture. I might agree with that, while remembering that everything comes with a price. This session is a summary of my experience with ES gathered while working on 4 different commercial products. Instead of theoretical aspects, I will focus on possible challenges with ES implementation. What could explode (very often with delayed ignition)? How and where to store events effectively? What are possible schema evolution solutions? How to achieve the highest level of scalability and live with eventual consistency? And many other interesting topics that you might face when experimenting with ES.

Event Sourcing - what could possibly go wrong?

Slow to innovate means being left out, but fast paced innovations means higher risks of service disruptions. Let’s see some common cases. The events that are too hard to reach, the apps that are too slow to change, and the clients that are oh so many at times. How some patterns with event-driven architecture can help?

Be faster and safer with EDA

Case study: how Lunar Bank prepares for hyper-growth with an event driven architecture as the foundation.

Since receiving their banking license from the Danish FSA back in August 2019, Lunar has been on the mission of providing an innovative and best-in-class banking experience across the Nordics. As a company deeply rooted in technology, the Lunar tech platform plays a crucial role in delivering on this mission.

A main technological focus point has from the very beginning been an event driven architecture with event sourcing as a core component. However, technological excellence is not enough to make the mission possible: organisational and structural matters, with domains and squads at the core, are equally important to deliver on the mission.

In this talk Brian and Thomas will give a report on the evolution of Lunar’s platform with a focus on answering the following:

- Strategic domain thinking: banking is a complex domain - what has Lunar done to slice the beast and find the sweet spot balancing ‘just in time’ development with scale and hypergrowth?
- Technology: building a modern bank from scratch is not a simple task - what principles has Lunar chosen for its architecture, why these choices, and where are we heading?

Furthermore, we will share how these 2 topics in our opinion cannot and should not be separated.

Keywords: Domain context mapping, event streaming and handling, CQRS, snapshotting, eventual consistency, inverse Conway

Event driven architecture & hyper-growth

Process Managers / Sagas / Orchestrations are one of the eternally discussed topics in Event Sourcing . We will cover how by properly defining the problem and goals we are trying to address ,the question "What is a process manager, and do I need one?"  becomes trivial both to answer, and to use.

Process Managers Made Simple

When moving to an Event Centric data model it often feels like all of the data modeling tools and skills we have built over the years in more traditional systems are lost. In truth it is the exact opposite. Not only can we bring all of our hard-won knowledge on Data Modeling with us, Event Centric systems give us new and exciting Data Modeling tools that enhance our traditional toolboxes. With practical examples we walk a straight line from traditional relation data models into best practice Event Models. In addition, we can apply well known rules from traditional modeling to know why these new models are ideal for various usages.

Data Modeling in an Event Centric World

Inspired by Pat Helland's excellent paper "Data on the Outside vs. Data on the Inside" we explore one of the most insidious anti-patterns seen in building integrated Event Driven Systems. The failure to correctly separate private and public data in event sourced integrations lead to endless trouble. Correctly segmenting and modeling public and private data is the most important element in building integrated Event Driven systems.

Data on the Inside: Understanding large scale system design in Event Driven Systems

Most systems will have to deal with future or deferred events. Even the most common example of software on the web — a blog — will have the ability to “publish” a post in the future at a certain time. Here are 4 patterns to deal with such a requirement.

4 Strategies for Future Events with Event Sourcing

Starting a project with an Event Sourcing approach can be challenging. You will need to select and rely on crucial infrastructural components such as  a message broker and an event store. Then you will have to merge your business logic with the wiring and glue code that are required by those. We’ve been there and we think we can help.
In this demo we will show you how you can easily create, code and run your project based on DDD, Event Sourcing and CQRS. All that thanks to tools like AxonIQ Initializr and the free tier of AxonIQ Cloud. 

Tools to easily create and run an event-sourcing based project

Strategies for dealing with concurrency conflicts in an event sourced system

Taming the Concurrency Crocodile

A discussion on what "state" means in a distributed/microservices architecture with some thought experiments to explain the problems.

What do you mean by “is”?

In recent years the Event Sourcing pattern has become increasingly popular. By storing a history of events it enables us to decouple the storage of data from the implementation of the logic around it. And we can rebuild the state of our data to any point in time, giving us a wide range of opportunities around auditing and compensation.

In this demo-heavy session you will learn how we can use Azure Event Hubs to process and store these events to build our own event store based on Cosmos DB. Moreover, we will also dive into options around connecting to other Azure services and even Kafka applications to easily implement this popular pattern in our own solutions.

Implementing an Event Sourcing strategy on Azure

For many years now, stateless-serverful has been the go-to pattern for building backend services. This pattern is well understood and supported by mature, powerful toolsets. While we have continually improved and fine-tuned stateless-serverful, we are always on the lookout for something better, something different that may significantly improve how we build and run our systems. Often, a better way to do things is to take things in an alternate direction. In this case, replace stateless with stateful, replace serverfull with serverless. So what is stateful-serverless? Well, that is what we will cover in this session. Using Java, we will show you an approach for building and deploying stateful-serverless microservices. Event-driven, event-sourced data is the core of this stateful serverless architecture. 

From Stateless-Serverful to Stateful-Serverless

We'll dive into events, what they are, what they aren't, and how you can use them in your code to build better systems.

What's In An Event?

Using the event sourcing support in the Marten library as a real world example, we're going to look at strategies to handle potential concurrency issues within our server side applications. We'll examine the usage of offline optimistic locking, serializable transactions, and very carefully use offline pessimistic locking.  
Doing a deep dive into Marten's asynchronous event projection processing, I'll show some strategies for parallelizing work through the producer/consumer pattern. We'll also examine how Marten parallelized work through data sharding, leader election, and work assignment throughout an application cluster. Just to make things harder, we'll also talk about the necessary instrumentation and error handling it's taken to keep all that parallel work synchronized in the face of intermittent errors.


Concurrency and Parallelism in Real Life Development

For quite a while, I've been thinking about how a typical event-sourced application could be made simpler, even in mainstream OO languages such as Java or Kotlin, if the domain model was implemented with pure functions. Not only would the domain model be easier to reason about, but also composable and easy to test without special frameworks. This talk will show an example of an event-sourced domain model written in a mainstream language (Kotlin) without any infrastructure dependencies whatsoever. We'll then continue by looking at Occurrent, an open-source event sourcing library for the JVM, to store the events returned from your domain model. We'll also talk about CloudEvents and why you might consider using them for event sourcing purposes.

Pragmatic Event Sourcing with Pure Functions

Are you interested in finding out more about Event Store Cloud? In this session, Mat McLoughlin (Head of Developer Advocacy) will demo some of the core functionality of Event Store Cloud including setting up a peering network and provisioning a new cluster. At the end of the session, you will understand how to create your account in the Console, set up a network and peer it with your cloud infrastructure, and provision an EventStoreDB cluster.

Introduction to Event Store Cloud

In the last 10 years we have applied event sourcing and CQRS in the development of our new ERP system. We now have almost two years of production experience. During these years we have run into interesting challenges that needed to be solved. 

In this session we share how we built a system with many thousands of event types, with the aim of serving thousands of companies and eventually millions of users.

A system with thousands of event types

Based on interviews with 25 engineers, in which we discussed 19 event sourced systems, we explore the rationale for and the context of event sourcing. Why do people use event sourcing, in what kind of systems do they apply it, and how satisfied are they. We also identify five challenges that practitioners experience: event system evolution, the steep learning curve, lack of available technology, rebuilding projections, and data privacy. 

We dig deeper into the first challenge, event system evolution. We uncover five tactics that engineers use in upgrading their event sourced system: versioned events, weak schema, upcasting, in-place transformation, and copy-and-transform.

In this talk we share the results of our scientific study on event sourcing. We do not share the experience of one company, or one product, but the accumulated experiences of 25 engineers.


Event system evolution - A Scientific Study on Event Sourcing, Lessons from Industry

When building an event-sourced systems, it's a common reflex to construct projections to answer queries efficiently instead of sifting through the event stream.  But have you really checked just how inefficient it is to just check the events?  We might just be able to find a clever way to index the events on the fly, making do without CQRS and projections entirely.

This talk is a report on a highly distributed application for configuration management in a large network of car shops among mobile devices that are only sporadically connected.

We started out maintaining some carefully chosen projections.  These were to be hard to maintain consistently, and, as it turned out, unnecessary: Just going through the events selectively was plenty fast enough.  This might be your application, too.  The talk also has some lessons on event synchronization in mostly-offline settings, and conflict management.


Experience Report: Event Sourcing without Responsibility

When one’s app is challenged with poor performances, it’s easy to set up a cache in front of one’s SQL database. It doesn’t fix the root cause (e.g. bad schema design, bad SQL query, etc.) but it gets the job done. If the app is the only component that writes to the underlying database, it’s a no-brainer to update the cache accordingly, so the cache is always up-to-date with the data in the database.

Things start to go sour when the app is not the only component writing to the DB. Among other sources of writes, there are batches, other apps (shared databases exist unfortunately), etc. One might think about a couple of ways to keep data in sync i.e. polling the DB every now and then, DB triggers, etc. Unfortunately, they all have issues that make them unreliable and/or fragile.

You might have read about Change-Data-Capture before. It’s been described by Martin Kleppmann as turning the database inside out: it means the DB can send change events (SELECT, DELETE and UPDATE) that one can register to. Just opposite to Event Sourcing that aggregates events to produce state, CDC is about getting events out of states. Once CDC is implemented, one can subscribe to its events and update the cache accordingly. However, CDC is quite in its early stage, and implementations are quite specific.

In this talk, I’ll describe an easy-to-setup architecture that leverages CDC to have an evergreen cache.

A Change-Data-Capture use-case: designing an evergreen cache

What constitutes a new application version? This question is not easy to answer from a technical point of view. Modern distributed application architectures make it harder, since they require versioning at multiple points. In this presentation, Oliver outlines many of the common difficulties you will encounter in an event-sourced application system. What to do when event structures change? Can read models be migrated? How do I test the new version before publication? What about running versions side-by-side? Oliver will address these questions and many more, and useful hints for your first event-sourced application, the version update to v1.0, round off the presentation.

Event-Sourced Application Systems: Publishing The Next Version

Everyone likes to talk about best practices. We'll go the other way round and gather all the worst practices to learn how to build the worst Event Sourcing system!
Event Sourcing is perceived as a complex pattern that’s challenging to learn. In fact, it's pretty simple, but the way it's taught may lead to such a conclusion. By going through the worst ideas, we'll also learn the essence of Event Sourcing.

Let's build the worst Event Sourcing system!

The world of business applications is changing. Monolithic applications are being broken up into smaller services. The inherent symmetry of CRUD operations has been bifurcated by the emergence of GraphQL and its discrete input and output types. Enterprise users are expecting their interfaces to have capabilities present in consumer apps they use in their personal lives. It is time for business application architectures to evolve.  

Borrowing ideas from EventSourcing and CQRS, we will go over in depth the design and implementation of an application that is helping power Netflix’s studio. We will discuss how this model is aligned with modern cloud-based architectures and capabilities desired in business applications. GraphQL, tracking data provenance,  observability and testing will all be discussed.

Event Sourced Business Applications

Using Event sourcing to support card payments at scale. How we moved from a mainframe based payments platform to a hybrid cloud based platform with Event sourcing at its core. 

Implementing Event sourcing at scale for card payments at Tesco

In this talk we will go through different use cases and design patterns (CDC, events, outbox pattern etc) for moving data from your web. services (and Databases) to an event store for analytics and real time computation. We will also discuss how this can be done in a type safe ways and the good, bad and ugly of each  design choice.

Streaming app changes to Event Store

Many organizations have chosen to go with a hybrid cloud architecture to give them the best of both worlds: the scalability and ease of deployment of cloud, and the security, latency & egress benefits of local storage.
Persistence of data on such an architecture can follow a write-back mode, where data is first written to local storage, and then uploaded to cloud asynchronously. However, this means that the applications cannot utilize the availability and durability guarantees of cloud, and the availability of storage is the availability SLA of on-premise hardware, which is almost always less than the availability SLA of Cloud.
By switching the order, i.e. performing uploads to cloud, and then hydrating on-premise storage, applications get the benefit of availability SLAs of cloud. In our case, this allowed us to move from three 9’s of availability (99.9%) of local storage to four 9’s (99.99%).
Instead of uploading in write-back mode, we duplicated the incoming stream to upload to both cloud and on-premise. For on-premise uploads that failed, we leveraged Kafka’s event processing to queue up objects that need to be egressed out of Cloud into the local storage.
This architecture allowed us to hydrate the local storage with objects uploaded to Cloud. Furthermore, since local storage space is limited, we periodically purged data out of local storage and created a secondary copy of the data on cloud by leveraging Kafka event processing.


Going from three nines to four nines using Kafka

The food wastage in India is 70 tonnes per year, and there is mismanagement at several layers. Approximately 20-30% of the wastage happens in the last mile, between wholesale traders, and retail mom-and-pop stores.

Is there something we can do about it? 

This was the problem statement I attempted to solve as a first engineering hire at a startup. Our customers were 12.8 million retail owners that deal in FMCG (Fast-moving consumer goods, such as food grains, tooth paste, etc.). The goal was to develop a platform for retail traders (mom and pop shop owners / small and medium business owners) to buy FMCG products from wholesale traders using an Android app.

We used cloud extensively to develop micro-services for a section of the population which is not very well versed with smartphones and technology. In this domain, data is very unstructured and we had to come up with challenging ways to representing this unstructured data for a slick browse and search experience.

We used Kafka as the event streaming platform in conjunction with DynamoDB, Elastic Search, and Redshift to build pipelines and systems on Cloud.

Data ingested by sellers in DynamoDB would be transformed and published in ElasticSearch & inserted into Redshift tables for analysis. I'd like to delve into these details as part of this session.

Using Kafka to solve food wastage for millions.

Architectures based in microservices have emerged
as a successful style to develop software. They are particularly
suitable to the cloud infrastructures, which provides several
benefits, such as flexibility, modularity, resiliency, scalability,
independency development and ease of deployment. However,
reach the best values in each one of them, imposes several
challenges. The most common include: balancing speed and
safety, data synchronization, versioning, discovery, debugging,
logging, monitoring, testing and fault tolerance. The problems
associated with these challenges have been subject to discussions in both formal and informal literature. This talk is focused on the circuit breaker pattern, which describes a good solution to reoccurring problems fault tolerance. Although the idea behind the pattern is easy, its configuration is different for
each application case and it could become complex according
to the organization requirements. This talk proposes that this
configuration can be addressed as an optimization problem and
in this sense, a genetic algorithm is developed to define the
properties required in its application.


EventSourcing Live 2022Coming soon

Need help? Contact us

Sponsors

Your brand here