Hi @SasikumarSP ,
Sorry for the delayed response. I have been on holiday for a bit and only managed to get back to your post now.
Thanks for the additional background on your usecase, very insightful.
I think what you probably need is a combination of good documentation of your flows in Event Portal + additional stats on topics at runtime once Solace has added OpenTelemetry support into the product.
For now, you could also log sender information from each message, if applications are adding something meaningful here, see https://solace.com/blog/inside-a-solace-message-using-header-properties/ for some details on the headers of a message, in particular the field senderid.
For your datawarehouse usecase:
Does your datawarehouse application go down or fall behind regularly?
Are other applications receiving the same messages?
In a publish/subscribe architecture it can be tricky to deal with one consumer falling way behind or being offline for a long time, if others are receiving the same messages and want to keep receiving messages.
Typically your datawarehouse application being offline may/should not justify stopping other critical business processes from receiving their real-time data.
Typically you would try to size the queues for your datawarehouse application accordingly to buffer all the data. But if that is not possible, because you are looking at buffering Gigabytes or Terrabytes of data (Solace currently supports up to 6 TB spool size), then you may want to look at staging your data in another cheaper and highly available storage solution before processing it with your datawarehouse application.
Solace is very good for real-time data distribution, but slow, lower priority consumers might be better off catching up from a storage solution that is designed for large volumes and longer time storage (think several Terrabytes of data).