Are message queues used for like/comment button of social media websites?

Question

Can anyone please throw some light on the architecture behind like/comment buttons of any social media website. (such as facebook, twitter or even stack overflow for that matter).

What I want to know is, when a user clicks a like button or clicks on submit when posting a comment, then what happens in the back end?

Is the data taken and stored in the database immediately and after that response is sent to the client? OR is some architecture such as message queues used to immediately send a response to the client and the processing (storing in database) is done later?

Please let me know if any technique such as message queues or anything else is used when these buttons (like,comment) are clicked or simply data is stored in database?

Any insights would be greatly appreciated.

thank you.

Answer 1

I have no idea. But if you're interested in architecture...

In a simple low-use hobby solution you can probably trigger a database update directly (where "directly" means via an API and through appropriate software layering: logic, dependency injection, data access code, database). In this solution, any part of the solution interested in the click might look up this data, and/or get triggered through some event-based approach.

Where you have scaled-out for high-use, a queue will allow you to capture the event and process it asynchronously. The server can accept the event, leaving the UI to carry on; the event can then be picked up by any one of the available subscribers.

If you're dealing with an especially high volume of events, caching could be another approach, where the cache is updated and used to serve other requests; and the event persisted asynchronously. There's a number of useful caching patterns which could have some application here, such as Write-Behind / Write-Back pattern.

Use of patterns, choice of technology and approach comes down to the various architectural drivers relevant to the solution context, which in the scenario you're talking about would include the expected volumes of events over time (writes and reads); the acceptable latency; degree of criticality for not losing an event; number of interested consumers components (depending on the complexity of the rest of the solution).