I have searched meta for an answer, but found only some bits. Interesting bits, but still something is missing from the big picture.

It is widely known that reputation is both updated on the fly, and can be re-computed on demand (starting from the beginning of time).

There are also several places where the general architecture and tools used by SO/SE are discussed (see for example this answer https://meta.stackexchange.com/a/10370/169617)

There is a very nice answer on how things are cached, at different levels, mainly using in-memory caches and redis https://meta.stackexchange.com/a/69172/169617 and another nice answer on the custom socket implementation to notify and update the UI in real-time for some counters https://meta.stackexchange.com/a/168148/169617, where a "unified messaging bus" is mentioned.

However, I did not find anything that explains what goes on this "unified messaging bus" and how it is implemented.

My question is: which counters and information in general do you update on the fly?

In particular, I would be very interested on how (the real mechanics) you do that: do you write the event (i.e. accept answer, question viewed, ..) on the DB, and then trigger some modules to do the recomputations? (badges, hot question list, rep...). Or is it vice-versa (you write the event on the cache/redis, and "write to DB" is one of the things "triggered" by the event?) Do you take advantage of redis pub/sub? How do you feed your websockets module? Where is protobuf-net inserted in the big picture?

  • 1
    Give us teh codez! Mar 26, 2013 at 9:02
  • 1
    @mattytommo Not really, I am more interested in the architectural choices than in the actual code, especially in how they deal with messaging/cache/db interactions Mar 26, 2013 at 9:43


You must log in to answer this question.

Browse other questions tagged .