shubhu02

MIght be. Although since modern inboxes use real time websockets (or other technologies like server-push events) to handlle concurrent real-time messaging, updating the database shouldn't cause issues with receiving the messages as they are sent (although retrieving the chats on reload can be an issue if that's the case). Anyways, the trouble was well worth it. Finally, Fiverr is using React for the front-end. Expect faster pageload speed, real-time effortless updates for various UI elements (like the dot on the notification bell and the number of messages for a chat) in real-time without the need of page reload. It's also gonna be much faster than the previous UI (considering how well React manages DOM manipulation with it's virtual DOM model), also expect future UI updates to be shipped faster (as React has state control built-in, is super modular and very developer friendly). I liked this decision of the tech team.

Hmm.. Well, it's strange to be honest. There can be multiple architectures a web app can use today. The most common and scalable architecture is the distributed microservices based approach that I mentioned above. Since you have observed this pattern for 8 consecutive years, it leads me to believe that the messaging system has multiple dependencies (as not every update should involve changes to the messaging system). These dependencies can and should be eliminated or at least reduced (or we all will need to open new threads to complain about the messaging system every time a change is made, like now). This technique is called beta testing. We devs always do it. Releasing early features to select users (beta testers) is a way to test a feature before it's released. This doesn't mean it's pushed to production already. Beta testers are served a separate app version which is independent of the production branch.

Just a litle correction here from a professional developer. Any updates are rearely done live to the production instance, not even very small tweaks let alone site-wide updates. We devs use local environments to develop and test features thoroughly on before we push the changes to production (live). The actual cause of this delayed processing is likely because of scalability issues with the servers that handle messages. As the messages are eventually processed it means that the requests have to be stalled and queued due to more requests than that can be handled concurrently.

Yes, the messaging system is down right now.