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.

Thank you!