STRING: Social-Transaction Routing over a Ring Idrissa Sarr*, Hubert Naacke**, and Abderrahmane O. M. Moctar* *University Cheikh Anta Diop - LID Laboratory, Dakar, Senegal idrissa.sarr@ucad.edu.sn, abderrahmane.md.moctar@hotmail.fr **UPMC Sorbonne Universit´ es - LIP6 Laboratory, Paris, France hubert.naacke@lip6.fr Abstract. A key requirement for social applications is to support fluid interactions among users. Basically, social applications deal with user- oriented data: users own their data and may access or modify data owned by others (say their friends). Therefore, several users may focus simul- taneously on a small piece of data (hot data) owned by the same user. Such a situation, more known as a net effect, has the drawback to gen- erate temporal peak loads able to slow user interactions. Moreover, a social application inherently generates multi-node (or multi-partition) transactions as far as users interact between them. Based on those observations, we propose String, a transaction schedul- ing layer that uses various strategies to order (or group) transactions based on their access classes. String reduces significantly the overhead cost of processing one transaction at a time while allowing to process rare multi-nodes transactions in en efficient way. The key novelties lie in (1) our distributed transaction scheduling devised on top of a ring to ease communication and (2) our ability to absorb peak loads as early as possible by splitting the transaction processing in two phases: a schedul- ing phase, resilient to peak load, followed by a group execution phase. We designed and simulated String using SimJava and we ran a series of experiments. Compared with some existing solutions, String shows interesting and promising results. Keywords: Transaction processing, load-aware query routing, data con- sistency 1 Introduction Social applications are becoming more and more popular in the realm of com- puter science, economic, politic, and so forth because they give a primary role to the user, capturing its profile and supporting its collaborative activity. They bring to the user an enriched experience that capitalizes its her/his social enroll- ment, more than ever. A key requirement for social applications is to support fluid interactions among users. Social applications deal with user-oriented data: a user owns some items and can add and/or modify the attributes related to the items owned by others. Such applications are both read and write intensive since