Engineering Blog - September 13, 2011

4 Tricks to Going Real-Time for Software Architects

Glenn Engstrand

In the past few months, we have added Real-Time Communication features to the Zoosk.com web site. These have included presence, notifications (toasts) and instant messaging. This is the first in a three part series on adding Real-Time Communications to your web app. In this first part, I propose four tips on preparing for the transition from a software architect’s perspective.

  1. Expect more load. As you reach deeper levels of integration between instant messaging and your web app, your chat servers will need to call your API layer to get additional information or business logic decision support. Also, the web tier will generate javascript that exchanges a lot of presence and messaging information with the chat server. This extra client to server and server to server communications can put unanticipated load on your system. Be sure to get deeply involved with the capacity planning that must be a part of any RTC deployment.
  2. Prepare for higher SLA. People expect real-time to be pretty fast. Your API calls may need to guarantee lower latency in order to satisfy that expectation. At Zoosk, we mitigated this problem through a lot of use of asynchronous message queuing.
  3. RTC uses long lived, stateful connections at every level. Web developers are used to the short lived, RESTful, stateless connection style of HTTP. There is a serious cognitive mismatch between those two styles. As the software architect, you are going to have to help the engineers revisit a lot of assumptions about how to put together complex systems when embracing RTC.
  4. This isn’t your daddy’s federation. Users connect to individual chat clusters and can make only one hop to get to the final destination. It’s the same problem as sharding. How do you partition the space more-or-less equally in order to minimize network latency? Many web sites avoid the problem by not using the federated parts to XMPP. This is not a scalable approach. At Zoosk, we avoided this pitfall by aligning our chat clusters with our user shards. Though each cluster can access any shard, that cluster also has a primary shard associated with it. The user must connect with the corresponding chat cluster for the database shard where their profile information resides.

While RTC can provide a huge boost of traffic to your web property. It does come at a serious price. Being prepared to take on the complex challenges of RTC will ease the pain of transitioning your web app to a real-time world. These four tips should give your software architect guidance on how to prepare.

Glenn Engstrand
Senior Software Engineer for Real-Time Communications
Platform Team