anchor.diff:  `customerId` to identify the customer placing the bid, and a `price` (we've used a long for this, which represents the
   value in cents).
   
  -<1> Pull the data out of the message.  This is similar to the pattern used in a Aeron Subscription's `onFragment`
  +<1> Pull the data out of the message. This is similar to the pattern used in an Aeron Subscription's `onFragment`
   callback when doing a poll.
   
   <2> Execute the business logic, in our case this is applying the incoming bid to the auction to see if it is a winner.
   
   <3> The `ClientSession` allows the service to get information about the calling client, but also provide a means to
  -return responses back to the client.  However it will be `null` during recovery, so we need to check for that state
  -and not offer a response in that case.
  +return responses back to the client.
   
   <4> Serialise response message.
   
  -<5> Calling `offer` on the client session will send the response on the egress channel.  Make sure that the return value
  +<5> Calling `offer` on the client session will send the response on the egress channel. Make sure the return value
   for `offer` is checked as it is a non-blocking call and not guaranteed to succeed.
   
   <6> When doing any busy loops within the clustered application use the Cluster's `IdleStrategy::idle(int)` within the
  -wait loop to allow the service to pause in a friendly manner.  It will take care of handling thread interrupts and
  +wait loop to allow the service to pause in a friendly manner. It will take care of handling thread interrupts and
   ensure the node fails correctly.
   
   === Storing State
   
   As was mentioned earlier we need to regularly take snapshots of the service's state in order to reduce the mean time to
  -recovery and facilitate release migration.  There is a callback `onTakeSnapshot` that will be called when it is time to
  +recovery and facilitate release migration. There is a callback `onTakeSnapshot` that will be called when it is time to
   snapshot the state of the service.
   
   Aeron Cluster provides an `ExclusivePublication` to write a snapshot as the serialised representation of the application
  -logic's state.  For real world applications snapshotting can become tricky.  The two big concerns you will have will be
  -ensure that snapshots are written in a consistent manner and dealing with fragmentation of the application state across
  -messages.  For now, our state is so simple that neither of those will impact us.
  +logic's state. For real world applications snapshotting can become tricky. The two big concerns you will have are to
  +ensure that snapshots are written in a consistent manner, and dealing with fragmentation of the application state across
  +messages. For now, our state is so simple neither of those will impact us.
   
   [source%autofit, Java, indent=0, options="nowrap"]
   ----
   include::{sampleSourceDir}/io/aeron/samples/tutorial/cluster/BasicAuctionClusteredService.java[tag=takeSnapshot]
   ----
   
  -<1> Write the persistent part of the application logic to a message buffer.  In our case, the currently winning customer
  +<1> Write the persistent part of the application logic to a message buffer. In our case, the currently winning customer
   id and bid price.
   
   <2> Write the message to the publication, again we need to check the return from the `offer` call and use
  
positive.code: 
  === Loading State
  
  Our `onStart` implementation contained a  method to load the snapshot.  Now that we have seen how the snapshot is
  written, we can look at how it is loaded.  The `Image` provided to the `onStart` has a method that will indicate if
  there is no more data available.  However, application code should also encode enough information that the end of the
  stream can be detected from the store messages.  The the two approaches can be used to do sanity checking that all of
  the data is received.
  
  [source, Java, indent=0, options="nowrap"]
  ----
  
negative.code: > ./basic-auction-cluster
  ----
  
  This will spit out a lot of logging but should end with something like:
  
  ----
  CLUSTER: ELECTION_STATE_CHANGE, FOLLOWER_TRANSITION -> FOLLOWER_READY, memberId=2
  