Message Queues
Message Queues
Our application has evolved. Instead of one large program, it is now made up of many smaller services. One service processes payments. Another updates inventory. Another sends emails. Another generates invoices. Now imagine a customer places an order. Should the payment service wait until every other service finishes its work? If the email service becomes slow... Should the entire order process stop? The engineering problem was clear. How do independent services communicate without depending on each other's speed or availability? The engineering concept that solved this problem is Message Queuing. Instead of sending requests directly, one service places a message into a queue. The receiving service processes that message whenever it is ready. The sender doesn't wait. The receiver doesn't need to be online immediately. The queue acts as a reliable buffer between services. Amazon Web Services provides this through Simple Queue Service (SQS). Microsoft Azure provides Azure Queue Storage and Azure Service Bus. Google Cloud provides Pub/Sub for asynchronous messaging. Different names. One engineering concept. Applications became more reliable because individual services could fail, recover or scale independently without bringing the entire system down. But another question soon emerged. Sometimes one event needs to notify many services at the same time. Do we really need to send the same message to each service separately?