Thoughts for the Velocity Team
Here’s my take on Velocity in answer to the team’s recent posting asking for thoughts on “Would you use this functionality, and how/when ? What kinds of data would you like to cache? What features do you think will make this a better story? What pieces of functionality are completely missing?”
- I really don’t care about ASP.Net SessionState integration
- Market data – I want to hold trade, market data (historical and ticking), curves, and reference data
- Usage from the perspective of a data fabric, grid and SOA. Grid’s are interesting from a investment bank (DataSynapse/Platform)/hedge fund (Digipede) arena – pricing trade being the minimum usage. If I’m pricing thousands of trade per day over my grid, I want to hit a distributed cache to retrieve “data” to avoid hot spots within databases if possible. Running Velocity on all/part of the grid nodes is therefore interesting.
- Push-based notifications is a must – don’t bother launching without it!
- Have a look at Gigaspaces, GemFire and Tangosol, and then improve on what they offer today from a distributed cache perspective.
- Guaranteed data access and resiliency
- Continuous query engine – VelocityLinq!
Tales from a Trading Desk 
I’m hoping they allow some kind of query mechanism. I’ve already written a continuous query engine for in-memory objects that is WPF-bindable (CLINQ – http://www.codeplex.com). Once they have push, my first task will be to see if I can rig Velocity to CLINQ.