- It's root in Domain Driven Design community
- Vaughn Vernon: Implementing Domain-Driven Design
- It isn't a good way to design databases. Instead, we should indivisualy record every change that happen to database.
- Events are immutable
- We don't loose historic information
- storing state:
- Store raw events (Event Stores)
- Used by analyst
- Offline processing
- Machine Learning
- Recommender system
- best for DB Writes (speed) (write optimized)
- source of truth
- immutable facts
- append-only streams of immutable events
- Aggregated Summaries; Store aggregated data (SQL databases, OLAP cubes, ...)
- Scanning raw data too slow
- react in real-time manner
- Monitoring, alerting, trending
- redis, memcached (atomic increment operation)
- best for DB Reads (speed) (read optimized)
- derived
- denormilised
- cached view of the event log
- normolization make write fast and simple, but it means you must do more work (joins) at read time.
- duplicate information in various places so tha it can be read faster
- benefits:
- Read and Write performance
- scalability
- Flexibility and Agility
- Human Fault tollerance
- Store raw events (Event Stores)
- timestamp
- action
- properties
- Multidimensional cube
- message queue
- event log
- multiple consumer
- archive row events
- aggregation
- monitoring
- event detection
- kafka client library: kafka streams
- kafka streams
- Spark Streaming
- Storm
- Samza
- Flink
- Stream query engines
- storm
- s4
- SQL like query language
- fraud detection
- monitoring business processes
- full-text search
- akka
- Erlang OTP
- Orleans
- bringing event streams to the user interface
- dataflow languages
- ReactiveX
- functional reactive programming (FRP)
- RxJava
- Elm
- Meteor
- React
- Golden Gate
- Databus
- append-only
- ordering -> kafka (AMQP or JMS does not support fixed ordering)
- less work at first
- race condition problem
- inconsistency
- Eventual
- Perpetual