Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Facebook and Twitter are not mid-size Rails applications. They are companies. The tech that runs them is distributed and mostly custom, especially in the case of Facebook. </p> <p>The part that you seem to be grasping for is <em>how they determine who to notify</em> in a performant and scalable way. This is where shit gets real. You can find a lot of information about the architecture behind each on of them, and there is certainly a lot of great stuff to help you think about these things, but ultimately none of it is going to be something you implement into whatever application you're building. </p> <p><a href="http://www.quora.com/What-is-Facebooks-architecture" rel="nofollow noreferrer">http://www.quora.com/What-is-Facebooks-architecture</a></p> <p><a href="https://stackoverflow.com/questions/3533948/facebook-architecture">Facebook Architecture</a></p> <p><a href="http://www.infoq.com/news/2009/06/Twitter-Architecture" rel="nofollow noreferrer">http://www.infoq.com/news/2009/06/Twitter-Architecture</a></p> <p><a href="http://engineering.twitter.com/2010/10/twitters-new-search-architecture.html" rel="nofollow noreferrer">http://engineering.twitter.com/2010/10/twitters-new-search-architecture.html</a></p> <p>Plenty more juicy details over at Quora. </p> <hr> <p>Unfortunately, none of this gets you closer to your goal. I think the most realistic thing for you to do to start out with woud be to simply tie in a service like <a href="http://pusher.com/" rel="nofollow noreferrer">Pusher</a> to send messages to clients without worrying about it, use an <a href="http://guides.rubyonrails.org/active_record_validations_callbacks.html#observers" rel="nofollow noreferrer">ActiveRecord Observer</a> to add notifications to a <a href="https://www.ruby-toolbox.com/categories/Background_Jobs" rel="nofollow noreferrer">background queue</a> where the workers actually send those notifications to Pusher. This is a day or less of work and it should scale well to at least 10k notifications a day. Once you start having performance problems, ditch the Observer and Pusher for something like Goliath that can handle both of the jobs locally.</p> <p>Bottom line, learn what you can about large and experienced systems that have been put through the paces, but mainly just to see what <em>problems</em> they ran into and <em>how they solved them</em>. These methods aren't the same among the big guys even, and they are going to vary for each implementation.</p> <p>Hopefully that helps point you in a good direction. :)</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload