If I understand your question correctly, you're asking what's a good design for a normalized feed. This is a somewhat trivial question of (i) picking which data fields (e.g. price, volume) to filter out from each feed and (ii) how to keep that in a trading system with minimal computational overhead.
Regarding (i)
I highly recommend you approach this in a test-driven manner. In other words, figure out what data your application is going to use downstream and 'reverse out' what you need to normalize upstream.
A trivial example: If your strategy just needs prices, there's probably little use in normalizing the match numbers. If your compliance and post-trade analysis is keyed by transaction times rather than sequence numbers, then you probably don't need that either.
Two tips that I can give you are:
- Don't overstretch yourself. It's easy to make the mistake of trying to normalize too many from day 1. You don't want to waste time trying to get spot FX, swaps, equity options, equities, exchange-traded futures etc. all onto the same normalized feed. It will probably take you a very long time before you're dealing with all that, and by the time you have to, you probably have someone else redoing this for you anyway.
- Think a bit about how you will maintain depreciated fields and version changes you make to your normalized feed. No matter how exhaustive your initial design, I guarantee you will encounter changes over the course of implementation and real-time use.
Regarding (ii)
Without knowing your exact architecture, the best answer we can give you is a collection of obvious software development tips: keep this in memory, minimize allocation and GC overhead, and minimize the number of times you're shuttling the data from thread to thread.
Important note
If you're trading based on more than 1 data feed, this is not something you want to do alone. It's seriously not worth your time. There's a reason why vendor normalized data feeds are costly, they take a lot of time to maintain.
The part I don't get about your question is: Bloomberg is a normalized data feed provider whereas FIX is sometimes used by exchanges directly, why are you normalizing across the two? Then you're just introducing unnecessary overhead in the Bloomberg path. I would just use Bloomberg alone if that's the case.