Future Updates

The following are the current limitations. I hope to remove them by the next version

1. Currently updates are only possible on a dedicated node, the primary replica.
2. The primary (leader) node cannot fail during the uptime of the system.
3. Membership is handled reliably by a provided subsystem (see section "The Arbiter"). New Replicas which wish to Join should send a Join call to Arbiter. But for a replica to leave, the current process is quite tedious by sending a manual Replcias(Set[ActorRef]) call to Primary Replica.
4. The update rate is low, meaning that no incoming requests are rejected due to system overload. In case of rejecting an update the store is left in a possibly inconsistent state which may require a subsequent succeeding write to the same key to repair it.
5. Clients are expected not to reuse request IDs before the request has been fully processed and responded to.
6. There is a small chance for the database to be in in-consistent state. Please refer the section "Consistency in the case of failed replication or persistence" in the overview.