Join 14K readers and level up you AWS game with just 5 mins a week. Every Monday, I share practical tips, tutorials and best practices for building serverless architectures on AWS.
Cohesion vs. Coupling
|
"High cohesion, low coupling" is one of the most misunderstood principles in software engineering. So, let's clear things up! TL;DRCohesion is about the internal focus of a thing - how well its components work together to fulfil a single purpose. Coupling is about the external relationships between things - how much they depend on one another. CohesionWhen applied to a code module, cohesion measures how closely related its functions are. An Authenticator module will likely have high cohesion because all its functions are related to handling authentication. On the other hand, a Utils module is likely a dumping ground for unrelated helper functions and will, therefore, have low cohesion. When applied to a system, cohesion measures how well its components (services, subsystems, etc.) work together to achieve a single goal. A service with well-defined boundaries and responsibilities will have high cohesion. Conversely, a system has low cohesion if its components are poorly aligned and have overlapping or unrelated responsibilities. For example, a User service that handles authentication, account management and sending notifications about account updates. CouplingA good way to think about coupling is in terms of change propagation. That is, how much does System B need to change if we change System A. Coupling is everywhere and comes in many different forms. Some coupling (e.g. data format dependency) requires coordinated changes between systems. Other forms of couplings are less obvious but more problematic to deal with. For example, temporal coupling links the availability of one service to another. This often leads to cascade failures and necessitates other practices (e.g. retries, exponential backoff, fallbacks, chaos engineering and so on) to mitigate. ----- So there you have it, the difference between "Cohesion" and "Coupling". They measure similar but, ultimately, different qualities in software. |
Master Serverless
Join 14K readers and level up you AWS game with just 5 mins a week. Every Monday, I share practical tips, tutorials and best practices for building serverless architectures on AWS.
During this week's live Q&A session, a student from the Production-Ready Serverless boot camp asked a really good question (to paraphrase): "When end-to-end testing an Event-Driven Architecture, how do you limit the scope of the tests so you don't trigger downstream event consumers?" This is a common challenge in event-driven architectures, especially when you have a shared event bus. The Problem As you exercise your system through these tests, the system can generate events that are consumed...
I recently helped a client launch an AI code reviewer called Evolua [1]. Evolua is built entirely with serverless technologies and leverages Bedrock. Through Bedrock, we can access the Claude models and take advantage of its cross-region inference support, among other things. In this post, I want to share some lessons from building Evolua and offer a high level overview of our system. But first, here’s some context on what we’ve built. Here [2] is a quick demo of Evolua: Architecture This is...
This edition of the newsletter is written by Raj Saha, Principal Solutions Architect working at AWS where he designed multiple world-scale systems. He has trained students to get SA jobs through his bootcamp, and runs a YouTube channel "Cloud With Raj" with over 114K subscribers. Since all of you Yan’s readers are pretty savvy technically, let me go over how to represent your technical knowledge in the (in)famous STAR format, to get hired at high paying jobs. All big tech companies, including...