New reference application

[krasserm]

The current reference application exists since the very first release of Eventuate. It has been developed as proof-of-concept for combining event-sourcing, global distribution, causal consistency and interactive conflict resolution. Many new Eventuate features have been developed since then so that the current reference application is not representative any more. We therefore want to implement a new reference application that additionally demonstrates some or all of the following features:

• Automated conflict resolution (with CRDTs or custom, application-specific data types)
• Causal consistency (e.g. in a globally distributed chat server, see also this presentation)
• Event collaboration (implementation of a reliable, distributed business process, ...)
• Event aggregation (from multiple event logs, multiple locations, ...)
• Event bus with limited or unlimited event retention time
• Event-sourced writers for maintaining persistent views
• Event-sourced processors for creating event processing pipelines
• Connectivity to event stream processing solutions via adapters (Akka Streams, Vert.x, Spark)
• Akka Streams API for consuming, idempotent processing and producing events
• ...

See the Reference documentation TOC for further topics. Other things we might cover are:

• integration into Akka Cluster, Akka Cluster Sharding or even Lagom
• deployments on AWS or other cloud platforms
• ...

or whatever. If you have any preferences what you'd like to see in a new reference application, please add a comment to this ticket or contact us in the forum.

[magro]

Perhaps it makes sense to have several samples demonstrating different aspects / features, instead of a single big one?

I already planned to build a (stripped down) ecommerce system consisting of different services like product service, teaser service and search service that focuses on demonstrating the value of causal consistency: the teaser service receives product related events and calculates product teasers based on some rules. The search service receives both product and teaser events. It should only display the teaser for a product if it got the product related event that caused the teaser event. This is a realistic issue in today's web shops that are built with microservices or Self-Contained Systems and rely on eventual consistency.

Of course this app would naturally use/demonstrate several features of eventuate.

[krasserm]

@magro +1, it's definitely important to demonstrate how application logic becomes simpler if applications can rely on a causally ordered event stream. An e-commerce example application would also be a good fit for a shopping cart service implemented with the shopping cart CRDT. I like your plan 😃

[magro]

@krasserm You're totally right, the webshop should have a shopping cart as well, of course! :-)

[hustnn]

How about the support of distributed transaction like Google spanner?

[hustnn]

It seems that my proposal is not correct. Goole spanner need strong consistency. Eventuate uses causal consistency. What kind of applications are applicable to the causal consistency case?

[volkerstampa]

@hustnn If you choose AP of CAP for a distributed application, i.e. you want that the application stays available for writes in case of network partitions, you cannot have strong consistency but have to live with eventual consistency. Causal consistency is the strongest from of eventual consistency you can have in the face of network partitions (see also here). Actually causal consistency also feels pretty natural or as Jonas Boner puts it in his report about reactive microservices: "Semantics based on causality is what humans expect and find intuitive."

So the question is less about which applications are applicable for causal consistency but more about availability requirements of your application.

Thea idea to implement a distributed chat server as reference application has its roots in the examples of this paper and it just illustrates nicely the effects of causal consistency versus eventual consistency.

[krasserm]

https://gitter.im/RBMHTechnology/eventuate?at=581301d70e25dbfa116d93c8

[hustnn]

@volkerstampa Thanks for the clear reply and the valuable references.

[magro]

Just stumbled over https://github.com/pawelkaczor/ddd-leaven-akka-v2, might also give some inspiration.

[seakayone]

I would appreciate if the reference application could include some simple show cases of how to test EventsourcedActors. I myself have tried to implement a simple example for an EventsourcedView but I am really not happy with it as I am currently lacking information of how to do it nicely.

[krasserm]

@seakayone this should actually go into #198. At the moment, it is recommended to follow the approach in the existing Eventuate tests.

[seakayone]

@krasserm thanks.

I have started myself with a basic example project which shows how eventuate could be used with SpringBoot: https://github.com/seakayone/spring-boot-eventuate-example