For Better Availability
Present
- When JMS ActiveMQ Server goes down, we loose whatever we have in Queues.
- JMS Queues are the single source of data when dependencies are down.
- Thus, it's a Single Point Of Failure (SPOF).
- Even with CTO ActiveMQ HA cluster, we cannot achieve partition tolerance from CAP theorem.
Future
- Using (locally) persistent Chronicle Queue can give us better Availability & Partition tolerance from CAP.
- Chronicle Queue uses just single file to store and retrieve the data.
- The system has one less remote dependency.
- Since Chronicle is designed to off-load JVM heap, it's ultra fast!
Present
Future
For Better Traceability & Auditing
Present
- The system stores some request and response of outbound calls in log files.
- Splunk is a great tool for manual troubleshooting, but isn't built for automation of data recovery via APIs.
- Relational DBs aren't designed for storing log and event data which requires different schema or schema-less datastore.
Future
- Store all inbound and outbound calls to NoSQL DB like Cassandra or Riak (has built-in Lucene)
- These NoSQL DBs are AP systems (CAP theorem). So, they have faster READ and WRITE.
- A potential alternative data lookup for RDBMS's slow queries.
- NoSQL DBs' APIs will enable to automate recovery processes.