The question I really have is how people have managed to upgrade their message bus and to keep availability high with rollback contingencies while upgrading, say, RabbitMQ or Kafka across all your connected services. I really don't hear about that as much as how to do rolling restarts / upgrades of nodes for a service endpoint using some feedback from monitoring and metrics.
"than" and beyond is an illogical statement. Like Y is Z than X.
From the React/Flux frontend paradigm, to the "everything is a stream" philosophy of Unix systems, to Erlang actors, to event sourcing for application backends, to databases like Datomic and CouchDB.
This is why I'm so excited about Elm right now - it explicitly puts this at the core of every application, and gives you a really nice language and type system for encoding your domain logic and manipulating data.
Time to write a blog post, I guess.
Event sourcing, on the other hand, is an internal implementation detail of a particular service... Which happens to get you a good stream of events as a side-effect.
> The work described in this thesis is the result of a research program started in 1981 to find better ways of programming Telecom applications. These applications are large programs which despite careful testing will probably contain many errors when the program is put into service. We assume that such programs do contain errors, and investigate methods for building reliable systems despite such errors. The research has resulted in the development of a new programming language (called Erlang), together with a design methodology, and set of libraries for building robust systems (called OTP).
[1]: http://ftp.nsysu.edu.tw/FreeBSD/ports/distfiles/erlang/armst...
If what you mean by sharing data is about dependency between calls to different services, e.g. A -> B -> C..., I would go with Storm and other stream processing frameworks, cause that is why those frameworks are built...