anchor.diff:  http://www.reactive-streams.org/[Reactive Stream] are an excellent way to model such client centric solutions.
   
   ==== Producer Centric solution
  +
   CQ doesn't have flow control deliberately, as flow control isn't always possible, or even desirable.
   
   Some examples of systems where CQ is often used are
  
positive.code: === What makes Chronicle Queue different from similar solutions
  
  ==== Speed
  CQ is designed to support hundred of thousands of messages per second comfortably.
  It can also handle multi-second bursts into the millions of messages per second.
  One of our clients reported they are handling bursts of 24 million messages per second with a cluster of 6 servers.
  
  ==== Without Flow Control
  CQ is an unbounded queue without flow control between the producer and the consumer.
  Replication supports flow control but this is not used by default.
  A lack of flow control is what we call a "producer centric" solution.
  
  ==== Consumer Centric solution
  To put that in context, most messaging solutions have flow control.  They are what we call a "consumer centric" solution.
  Consumer centric solutions make sense in many application esp between servers and client GUIs.
  Any data you send to a client GUI is for display to a human.
  
negative.code: For us a key feature of CQ is not just how the data structure is arranged,
  but also how transparently this binary data structure can be inspected.
  
  NOTE: The `SCQStore` "bootstraps" the queue itself.  If you provided another, custom implementation the queue could behave as you wish, provided it support the same interface.  The Rolling and Indexing strategies can also be customized.
  
  If we look at the last message, you can see the message type, the type of the payload and the value of all the fields.
  
  [source, java]
  