Complex Event Processing

Un agent (d'event processing) Source -> Channel -> Sink

CEP provides: tracabilité, réactivité, disponibilité, prise de décision

Architecture en Hexagone

Injection de Dépendance: SOLID (Dependency Inversion Principle) Low coupling, High cohesion Les objets métier ne doivent dépendre que d'injections (pour pouvoir changer facilement les implémentations techniques et rien d'autre, pas les objets métier)

A "implémente" x (interface) A "utilise" y (dependeny injection) -> easy test grâce à la DI (on peut envoyer des mocks)

Couches: Présentation, Métier, Persistence (gui, fonctions métier, ORM) : or, on mèle souvent du métier dans les @Entity..

Apache Camel

Framework d'intégration ou lightweight esb Implémente de nombreux patterns EIP, comme le "content based router" (des fichiers déposés somewhere sont traités, et en fonction du contenu, on écrit dans certains autres répertoires/fichiers) Intégration avec maven: mvn camel:run (camel-maven-plugin) Les processors doivent être stateless Du JMX pour gérer à chaud les routes On peut affecter plus ou moins de threads à la lecture des sources ou aux sinks (ainsi que les temps de polling) On peut également utiliser des routers comme un round-robin, faire du at-least-one (failover)

Database, CAP, AP etc.

Consistency = linearization (if action A has been saved, action B should see the state after A saved (or after another thing but still after A)). If you save something on a leader, and query a follower after, you must expect A's result applied. The memory in the CPUs/cores are not linearizable without applying a memory barrier (to commit into the RAM) because each core has its own cache not synced.

Availability = all alive nodes should be able to respond properly

There are more failures than just Network Partition failure (reboot, shutdown, no more disk, bug..) No concept of latency. (it's slow but respond, that's still available right?)

Imagine 2 nodes with replication. Then network partition. You can't write to both nodes without losing consistency. You can stop all writes to keep consistency. You can stop one node to accept read and write and let the other take them. It's still consistent. If the clients can be redirected to it (like through a LB), you have a consistent, available, and network partition tolerant software.

Imagine 2 nodes, a leader and a readonly replica (often the case). Then network partition. If you can't write to the leader, it's not Available. And nor it's consistent (because the replica could be lagging).

Linearization slows down performance `(must make sure to commit everywhere).

ZK is not read linearizable, not read consistent (multiple nodes you can read from can give you a different value). You can enable the linearization, using a "sync; get /..." to ensure you have the last data, but that's more slow.

SLA: 99.99%

MVCC: Multi Version Concurrency Control (provides a fixed (transactional) view to client connections)