Skip to content
Pablo Rodriguez

Decoupling Architecture

Decoupling refers to the separation of components in a system so that they can operate independently. This approach addresses the challenges of tight integration by creating more resilient and scalable architectures.

  • Synchronous Communication: All communication requires “send and wait for reply” patterns
  • Direct Dependencies: Web servers communicate directly with application servers
  • Scaling Complexity: Adding new servers requires code updates to handle new IP addresses
  • Single Points of Failure: Application server failure means entire system failure
    • If application server fails, whole system goes down
    • System maintenance requires bringing entire system offline
    • Each new server requires multiple connections that must be updated in code

When scaling a tightly coupled system, complexity increases dramatically. Adding components requires establishing multiple new connections across layers:

  • Adding one web server requires three new connections (Route 53 + two application servers)
  • Adding one application server requires three new connections (from each web server)
  • Manual handling of application outages affects all connected components

Monolithic Applications create tight coupling when business functions are implemented and deployed as a single unit:

  • Single function problems can slow down or stop the entire application
  • Changes to one function require entire application maintenance
  • Example: Finance, transcoding, and calculation functions all running in same process
    • Transcoding slowdown degrades entire application performance
    • Can make whole application unresponsive

Elastic Load Balancing (ELB) as intermediary component:

  • ALB load balancer in front of web servers distributes traffic from Route 53
  • Second ALB between web and application servers handles workload management
  • Benefits:
    • Automatic health monitoring sends traffic only to healthy instances
    • Automatic failover routing
    • Adding new web server requires only two connections (to each ALB)

Microservice Architecture divides application functions into independently scalable parts:

  • Each microservice runs in its own process and maintains its own data
  • Functions exposed through well-defined APIs
  • Benefits:
    • Components can scale and fail independently
    • Changes to one component don’t affect others
    • Reusable, scalable, and reliable components
    • Can use synchronous or asynchronous communication

Example: Finance microservice scaled to three containers while calculations runs in one, based on different request volumes.

Use producer-consumer model for interactions that don’t need immediate responses:

  • Producer: Component that generates events
  • Consumer: Component that processes events
  • Intermediate Storage: Queue or topic handles message passing

Transform synchronous transcoding to asynchronous:

  1. Microservice becomes message producer, stores image in S3
  2. Places message in SQS queue for consumer processing
  3. Immediately responds to user for new request acceptance
  4. Consumer application polls queue and processes images independently
  5. Uses Amazon SNS topic to notify user when transcoding completes

Enables loose coupling between on-premises and cloud applications:

  • On-premises applications send messages through Amazon MQ broker
  • Broker stores messages using Amazon EFS or EBS
  • Provides message-based interface for cloud consumer applications
  • Supports flexible and consistent integration patterns
  • Infrastructure Level: ELB load balancers
  • Application Level: Microservice architecture
  • Queue Based: Amazon SQS for point-to-point messaging
  • Topic Based: Amazon SNS for publish-subscribe patterns, Amazon MQ for both models

Loose coupling isolates component behavior from dependencies, increasing resiliency and agility while preventing failure propagation between components.

Architecture Pattern