anchor.diff:  - you have a record of the order of the inputs you processed.
   - you have a record of all the decisions your new system is commited to, even if the new code would have made different decisions.
   
  -=== Guarentees
  -
  -Chronicle Queue provides the following guarentees
  +=== Guarantees
  +
  +Chronicle Queue provides the following guarantees
   
   - for each appender, messages are written in the order the appnder wrote them. Messages by different appenders are interleaved.
   - for each tailer, it will see every message for a topic in the same order as every other tailer.
   - when replicated, every replica has a copy of every message.
   
  -Replication has three levels of gaurentees
  +Replication has three levels of gaurantees
   
   - replication happens soon but eventually (< 1ms in as much as 99.9% of cases)
   - or, a tailer will only see messages which have been replicated.
  
positive.code: 
  Most messaging systems are "Consumer Centric", a common example is a user GUI.  
  You can have multiple users on different machines, different quality of networks, doing a variety of other things for the user at different times.
  In particaulr, a user can only take in som much data. For this reason it makes sense for the client consumer to tell the producer when and when not to give them more data. 
  It should detemine how flow control works.
  
  Chronicle Queue is a "Producer Centric" solution and does everything possible to never push back on the producer or tell it to slow down.
  As such it is a power tool as a big buffer between your system and an upstream producer you have little or no control over.
  
negative.code: 
  === Efficiency
  
  We put significant effort into worrying about latency you can't see.  Unlike products which focus on support of the web, we care about latency which are a fraction of the time you can see. For web application less than 40 ms is fine for web applications as it's faster than you can see (the frame rate of cinema is 24 Hz or about 40 ms)  However we attempt to be under 40 microsecond 99% to 99.99% of the time.  Using queue without replication we support applications with latencies below 40 microseconds end to end across multiple services.  Often the 99% latency of queue is entirely dependant on the chose of OS and disk subsystem.
  
  === Compression
  
  