The document discusses the use of event sourcing to reliably publish events during state changes in applications, highlighting its atomicity by persisting state as events. It contrasts the advantages of event sourcing with challenges in object-relational mapping and describes the concept of eventual consistency in distributed systems, including the CAP theorem. Additionally, it introduces the Eventuate framework, which facilitates event-driven programming for microservices, focusing on features like automatic event publishing and support for temporal queries.

2. Problem
How to reliably/atomically publish
events whenever state changes?
Solution
A good solution to this problem is to use event sourcing. Event sourcing persists the state of a business
entity such an Order or a Customer as a sequence of state-changing events. Whenever the state of a
business entity changes, a new event is appended to the list of events. Since saving an event is a single
operation, it is inherently atomic. The application reconstructs an entity’s current state by replaying the
events.
Applications persist events in an event store, which is a database of events. The store has an API for
adding and retrieving an entity’s events. The event store also behaves like a message broker. It provides
an API that enables services to subscribe to events. When a service saves an event in the event store, it is
delivered to all interested subscribers.
Some entities, such as a Customer, can have a large number of events. In order to optimize loading, an
application can periodically save a snapshot of an entity’s current state. To reconstruct the current state,
the application finds the most recent snapshot and the events that have occurred since that snapshot. As
a result, there are fewer events to replay.

3. Example
Customers and Orders is an example of
an application that is built using Event
Sourcing and CQRS.
Instead of simply storing the current state of each order as a row in an ORDERS table, the
application persists each Order as a sequence of events. The CustomerService can
subscribe to the order events and update its own state.

4. Order Aggregate

5. Here is an example of an event handler in the CustomerService that
subscribes to Order events:
It processes an OrderCreated event by
attempting to reserve credit for the orders
customer.

6. Benefits
• It solves one of the key problems in implementing an event-driven architecture and
makes it possible to reliably publish events whenever state changes.
• Because it persists events rather than domain objects, it mostly avoids the
object-relational impedance mismatch problem.
• It provides a 100% reliable audit log of the changes made to a business entity
• It makes it possible to implement temporal queries that determine the state of an
entity at any point in time.
• Event sourcing-based business logic consists of loosely coupled business entities
that exchange events. This makes it a lot easier to migrate from a monolithic
application to a microservice architecture.

7. The Object-Relational Impedance Mismatch
'Object-Relational Impedance Mismatch' (sometimes called the 'paradigm mismatch') is just a fancy way of saying that
object models and relational models do not work very well together. RDBMSs represent data in a tabular format (a
spreadsheet is a good visualization for those not familiar with RDBMSs), whereas object-oriented languages, such as Java,
represent it as an interconnected graph of objects. Loading and storing graphs of objects using a tabular relational
database exposes us to 5 mismatch problems…​
Granularity
Sometimes you will have an object model which has more classes than the number of corresponding tables in the database
(we says the object model is more granular than the relational model). Take for example the notion of an Address…​
Subtypes (inheritance)
Inheritance is a natural paradigm in object-oriented programming languages. However, RDBMSs do not define anything
similar on the whole (yes some databases do have subtype support but it is completely non-standardized)…​
Identity
A RDBMS defines exactly one notion of 'sameness': the primary key. OOP language, e.g., Java, however, defines both
object identity a==b and object equality a.equals(b).
Associations
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMSs use the notion of
foreign keys. If you need bidirectional relationships in Java, you must define the association twice.
Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
Data navigation
The way you access data in OOP language, e.g., Java, is fundamentally different than the way you do it in a relational
database. In Java, you navigate from one association to an other walking the object network.
This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL
queries and thus load several entities via JOINs and select the targeted entities before you start walking the object
network.

8. Bad Thing
The single biggest bad thing that has been seen during the last ten
years is the common anti-pattern of building a whole system
based on Event sourcing. That is a really big failure, effectively
creating an event sourced monolith. CQRS and Event sourcing are
not top-level architectures and normally they should be applied
selectively just in few places.
‘’ Martin Fowler ‘’

10. Eventual consistency
Eventual consistency is a consistency model used in distributed computing to achieve high availability that
informally guarantees that, if no new updates are made to a given data item, eventually all accesses to
that item will return the last updated value. Eventual consistency is widely deployed in distributed
systems, often under the moniker of optimistic replication, and has origins in early mobile computing
projects. A system that has achieved eventual consistency is often said to have converged, or achieved
replica convergence. Eventual consistency is a weak guarantee – most stronger models, like linearizability
are trivially eventually consistent, but a system that is merely eventually consistent does not usually fulfill
these stronger constraints.
Eventually consistent services are often classified as providing BASE (Basically Available, Soft state,
Eventual consistency) semantics, in contrast to traditional ACID (Atomicity, Consistency, Isolation,
Durability) guarantees. Eventual consistency is sometimes criticized as increasing the complexity of
distributed software applications. This is partly because eventual consistency is purely a liveness guarantee
(reads eventually return the same value) and does not make safety guarantees: an eventually consistent
system can return any value before it converges.

11. ACID VS. BASE
Atomic: Everything in a transaction succeeds or the entire transaction is rolled
back.
Consistent: A transaction cannot leave the database in an inconsistent state.
Isolated: Transactions cannot interfere with each other.
Durable: Completed transactions persist, even when servers restart etc.
•Basically Available indicates that the system
does guarantee availability, in terms of the CAP
theorem.
•Soft state indicates that the state of the
system may change over time, even without
input. This is because of the eventual
consistency model.
•Eventual consistency indicates that the
system will become consistent over time, given
that the system doesn't receive input during
that time.
Note: Both CAP Theorem and BASE are devised by Eric Brewer
Note: BASE Acronym is Contrived

12. CAP Theorem
There is a computer science theorem that quantifies
the inevitable trade-offs. Eric Brewer’s CAP theorem
says that if you want consistency, availability, and
partition tolerance, you have to settle for two out of
three.
Partition tolerance means the system will continue to
work unless there is a total network failure. A few
nodes can fail and the system keeps going.)

13. Amazon Violates I in ACID
Amazon might violate the “I” in ACID by tolerating a small
probability that simultaneous transactions could interfere with
each other. For example, two customers might both believe that
they just purchased the last copy of a certain book. The company
might risk having to apologize to one of the two customers (and
maybe compensate them with a gift card) rather than slowing
down their site and irritating myriad other customers.

14. Eventuate Framework
The Eventuate Platform provides a
simple yet powerful event-driven
programming model that solves
the distributed data management
problems inherent in a
Microservice architecture. The
programming model is based on
two well established patterns:
Event Sourcing and Command
Query Responsibility Segregation
(CQRS). Eventuate consists of a
scalable, distributed event store
server and client libraries for
various languages and frameworks
including Java, Scala, and the
Spring framework.
Key benefits of the Eventuate Platform
•Easy implementation of eventually consistent
business transactions that span multiple
microservices
•Automatic publishing of events whenever
data changes
•Faster and more scalable querying by using
materialized views
•Reliable auditing for all updates
•Built-in support for temporal queries
•Available as either a service (SaaS) hosted on
Amazon Web Services or as an open-source
project that you can run locally.

15. Materialized view
In computing, a materialized view is a database object that contains the results of a query. For
example, it may be a local copy of data located remotely, or may be a subset of the rows and/or
columns of a table or join result, or may be a summary using an aggregate function.
The process of setting up a materialized view is sometimes called materialization. This is a form of
caching the results of a query, similar to memorization of the value of a function in functional
languages, and it is sometimes described as a form of pre-computation. As with other forms of
Pre-computation, database users typically use materialized views for performance reasons, i.e. as
a form of optimization.
Materialized views which store data based on remote tables are also known as snapshots.
In any database management system following the relational model, a view is a virtual table
representing the result of a database query. Whenever a query or an update addresses an
ordinary view's virtual table, the DBMS converts these into queries or updates against the
underlying base tables. A materialized view takes a different approach: the query result is cached
as a concrete ("materialized") table (rather than a view as such) that may be updated from the
original base tables from time to time. This enables much more efficient access, at the cost of
extra storage and of some data being potentially out-of-date. Materialized views find use
especially in data warehousing scenarios, where frequent queries of the actual base tables can be
expensive.
In a materialized view, indexes can be built on any column. In contrast, in a normal view, it's
typically only possible to exploit indexes on columns that come directly from (or have a mapping
to) indexed columns in the base tables; often this functionality is not offered at all.