On failure of a client, the user perceives the session as lost, e.g., if the browser crashes, a user does not necessarily expect to be able to resume his interaction with a web application. If cookies for the client are persisted, as is often the case, then the client may be able to resume his session when the browser is restarted.
On failure of a stateless application server, a restart of the server
is sufficient for recovery. After restart, the stub on the server
detects existing bricks from the beacons and can reconstruct the table
of live bricks. The stub can immediately begin handling both read and
write requests; to service a read request, the necessary metadata is
provided by the client in the cookie. To service a write request, all
that is required is a list of 
live bricks.
On failure of a brick, a simple restart of the brick is sufficient for
recovery. The contents of its memory are lost, but since each hash
value is replicated on 
other bricks, no data is lost. The next
update of the session state will re-create new copies; if
additional failures occur before then, data may be lost.
A side effect of having simple recovery is that clients, servers, and bricks can be added to a production system to increase capacity. For example, adding an extra brick to an already existing system is easy. Initially, the new brick will not service any read requests since it will not be in the read group for any requests. However, it will be included in new write groups because when the stub detects that a brick is alive, the brick becomes a candidate for a write. Over time, the new brick will receive an equal load of read/write traffic as the existing bricks, since load balancing is done per request and not per hash key.