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.
- 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.
- 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.
- 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.
Senior Software Engineer for Real-Time Communications