{"id":5822,"date":"2023-05-12T08:17:54","date_gmt":"2023-05-12T06:17:54","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=5822"},"modified":"2023-05-12T08:17:56","modified_gmt":"2023-05-12T06:17:56","slug":"3-ways-to-decouple-your-microservices-sqs-queues-elb-load-balancing-and-sns-notification-system","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/3-ways-to-decouple-your-microservices-sqs-queues-elb-load-balancing-and-sns-notification-system\/","title":{"rendered":"3 ways to decouple your microservices: SQS queues, ELB load balancing, and SNS notification system"},"content":{"rendered":"\n

Why is service decoupling so important? And why should we avoid the tight coupling?<\/h2>\n\n\n\n

Monolithic architecture has served us well and had its time to shine but, in the early days of the web, companies needed a system to empower users to manage and deliver content. A monolithic architecture provided a solution that is an all-in-one, or \u201ccoupled,\u201d system with a codebase that pulled in everything necessary for managing and publishing content to the web. With this type of architecture, all processes are tightly coupled and run as a single service.<\/p>\n\n\n\n

Adding or improving a monolithic application\u2019s features becomes more complex as the code base grows. Monolithic architectures add risk for application availability because many dependent and tightly coupled processes increase the impact of a single process failure. So, here is the problem, if the big monolithic brain fails, everything fails.<\/p>\n\n\n\n

To overcome this problem we can make use of microservices, which are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs and performed single function.<\/p>\n\n\n\n

Because they are independently run, each service can be updated, deployed, and scaled to meet the demand for specific functions of an application, everything without affecting the functioning of other services. On a single service, more developers contribute to producing the code and, if the service becomes complex over time, it can be broken into smaller services.<\/p>\n\n\n\n

In this article, we will explain a use case inspired by a real-world scenario. We will demonstrate how to resolve different problems by using three AWS services with the aim of decoupling our architecture:<\/p>\n\n\n\n