In that moment, the idea of using messaging queues came into our minds. We could not lose any communication, and with that, any synchronization of data at all. We needed to have a certain queuing mechanism that would hold the communications in case that the receivers are too busy to respond, but, at the same time, we did not want to block the producer neither (by retrying requests again and again). Also, the pattern allows you to turn it around and make the subscriber the publisher of new information and have the possibility of a bi-directional synchronization in the case of future needs.īack then we faced the fact that we had to build a world wide publish-subscribe pattern, where the core had to be talking with services that we may not know if they are up and running and, the most important thing to do was to be reliable due to the high amount of traffic that we expected (not only core to region traffic but also traffic that is generated in the region, too). The publish-subscribe pattern was fitting perfectly in our project because all data that had to be synchronized was always in one direction. Core is the name we give to the place where the central database and the e-commerce part are, and the regions are parts of the world where we set our components (Europe, America, Asia.). Some time ago, when we started the descentralization of the huge monolith we needed a way to synchronize data between the core and the regions. If you were looking for a real use case and a discussion about when to use each protocol and why, then you are in the right place. ![]() If you were looking for that information here, just “let me google that for you”: AMQP, HTTP. But then I realized that all that grey information is out there, anyone that wants to read about the protocol itself can just "google it" and have plenty information about each protocol. When I thought about writing about "AMQP vs HTTP" I thought on writing differences between both protocols, describe every single header and why it is there, how it is the flow of each message/package your are sending in each protocol, etc, etc, etc.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |