Chronicle and similarities to Enterprise Service Bus (ESB)

Chronicle is not a replacement for an ESB as it tries to solve the same problems in very light weight way. This works very well for green field project work where you are happy to design your application (or a small portion) around reactive principles e.g. In a trading environment.
If you have existing application which is designed around the models an ESB uses, it is not a drop in replacement, nor should you attempt to do that IMHO.

Chronicle Queue is more that a persisted store and it is very good fit where speed, simplicity and determinism are key principles.

For example, a typical message takes about one micro-second to serialized and the same for deserialization. Faster if you read just one field for filtering. All this can be done without creating any garbage so no GC impact. You can read and write across processes on the same machine without a system call being involved or even any locks. Add to that, you get complete traceability allowing you to recreate the state of a process either downstream or in testing. A down stream system never needs to interrupt an upstream system to ask it about state as the down stream system can see every state change the upstream system has ever made. I.e complete transparency.

Solving a problem this way means your program is actually much simpler. I don't need tens of machines to process 100,000 msg/sec, in fact you don't even need a whole machine, just a writing and reading thread and they might be 90% idle.

This means your development cycle is much faster as developers can quickly start complete systems on development PC rather than time share a distributed test system. I am a big believer that the fastest development model is to be able to press Run in your IDE and this gives you a self contained system in seconds or you press Debug and you can debug your system trivially.

Peter Lawrey