Your app is not real time if anything blocks

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter.

Interesting:

(My background: I work for Google, I did a real-time web prototype using the client libraries for GChat back in 2009 when real-time search was all the rage, my Noogler mentor at Google was the frontend tech lead for the eventual real-time search product we launched, and before Google I’d worked in financial software, where real-time responsiveness really is required.)
I think that the folks currently building prototypes in Meteor dramatically underestimate the difficulty of scaling up real-time software to production-grade quality.
The problem is that if a single component in your stack blocks, you are no longer real-time. Any time one client writes into the database and another reads it, you have to poll, since the DB won’t give you notifications. (Exception: PostGres gives you PQnotifies, Oracle gives you the User Messaging Service, MySQL it’s theoretically possible with triggers and user-defined stored procedures that make a network call, and MongoDB you can break the DB abstraction and tail the oplog. Good luck plumbing any of these up through your language DB driver and ORM, though.) If you have business logic in a middle-tier server that’s request-response only, then that logic becomes a synchronization bottleneck, and you have to constantly update that server and poll it with requests. If your algorithms require complete state snapshots, you’re out of luck unless you build a service to manage and update that state consistently while triggering the algorithms whenever it changes. If your algorithms can’t run in soft-realtime time guarantees (dozens to hundreds of milliseconds, usually), you’re still out of luck. You need to figure out sharding of state and message notifications yourself. You need to figure out message recovery protocols – most real-time systems have odd consistency problems when messages get dropped due to overload, network failures, or software errors.
Google’s real-time search ended up polling every 15 seconds with simple AJAX calls, because when the lag for a post to go through the indexing & serving pipeline is a minute or two (itself a major accomplishment), an additional 15 seconds isn’t going to be noticeable to the user.
People on HN love to hate on Twitter engineering, but one thing they’ve done really well is scale a system that actually is soft real-time and has a lot of potential producers and consumers. This is far from the trivial exercise that someone who picked up Meteor in a weekend might think it is.

Post external references

  1. 1
    https://news.ycombinator.com/item?id=7046876
Source