# Towards a Highly Available Model for Processing Service Requests Based on Distributed Hash Tables
## 2 Materials and Methods
### System Scalability Based on the Intrinsic Properties of the Chord DHT
An exception is in the case that at a certain moment that peer fails, in which situation _its entire functionality_ will be taken by another previously designated backup peer, according to the DHT rules of replication on neighbors. The backup peer will also have to possess the up-to-date journal of the current client's session and data. Note that the keys that peer \(p\) is responsible for are also Chord IDs and each peer is responsible for the Chord IDs that are situated between its predecessor and himself, i.e., the keys that a peer \(p\) is responsible for are:

\[ChordID_{predecessor(p)}<ChordID_{key(p)}\leq ChordID_{p}.\]

Given the way of serving clients involving the load balancer from our improved solution, whenever it is possible, for each client's request to the service, except for the initiating request, the client is able contact directly the peer that is responsible for it. That peer will also ensure to store the data related to that client such that it is persistent and reliable, in case the peer itself should fail and thus disappear from the network. In case a peer disappears from the network, the clients that used to contact it directly, without using the load balancer any more, will notice that the peer's IP address can no longer be reached, and will thus naturally try to contact the service again, via its DNS name. This DNS interrogation will lead the client again to a load balancing node, which is a part of the load balancer. The load balancer will hand over each client to the new peer responsible for that client, by computing the hash of the client's name again, and by transparently routing again towards the peer that is responsible for the client's key, i.e., the Chord ID obtained by hashing that client's name. The currently identified peer will know, from the persistent and journalized data that were kept in the highly available database, how to continue the dialogue with that client, without affecting too much its quality of experience. A very important aspect here is that, for the service's clients, the entire Chord layer from the decentralized service, that processes requests, is totally transparent. Each service instance running Chord peers treats the improved decentralized service's clients identically to the situation when the service was centralized. By decentralization, the service's availability to more, old and new, clients is highly improved, since we have _removed_ the single points of failure. Since another peer is able to take an unavailable or failing peer's clients, to continue to offer them the service, there exists the _strong need_ to keep any client's data persistent within the entire decentralized distributed system of service processing nodes. For this, a _decentralized highly available_ database is used, also based on the Chord DHT, which, in the improved vision of a solution for highly available services, represents a _necessary basic condition_. This database, previously designed by our team, which is also based on the DHT, handles persistence, scalability and integrity aspects for the data. The novel method presented in this section, which can be schematically observed in Figure 4, should be generic enough to make any service highly available, with minimal

\[Finger_{k}\approx ID_{p}+2^{k},\]0 Generic handling of a client by the decentralized distributed service. modifications, by using the deployed load balancing nodes, contained in the deployed service-aware Chord layer. The Pre-Existent DHT-Based Distributed Database to Reliably and Persistently Store the Data Belonging to a Highly Available Service's Clients

Our team's previously published contribution to the field of distributed databases, which this solution relies on, resides in the fact of having identified a way to solve the problem of data loss, and more importantly of critical data loss, by storing the data on newly added nodes to the underlying DHT infrastructure, which is shared by the service and the database described in [7; 16; 17].