Tightly coupled system
In a tightly coupled design the login service calls the fraud service directly and waits for it to process the event before continuing. Because the login service depends on the fraud service being available and responsive, the two services become tightly coupled. Key consequences of tight coupling:- Direct dependency: producer (login service) calls the consumer (fraud service) directly, creating a single point of failure.
- Synchronous communication: the producer blocks until the consumer responds, increasing latency and reducing throughput.
- Reduced flexibility: changing, adding, or scaling downstream checks may require changes and redeployment of the login service.
- Poor fault tolerance: if the fraud service is down, login processing can be blocked or fail, which may cause cascading failures.
Tightly coupled systems are simpler to implement for small or latency-sensitive flows, but they reduce resilience and make independent evolution of services harder.
Loosely coupled system (event-driven)
A loosely coupled design uses a central messaging layer (message bus / event broker). Instead of calling the fraud service directly, the login service publishes a login event to the message bus and continues immediately without waiting for downstream processing. The message bus persists events until consumers (fraud service, auditing, analytics) fetch and process them. Consumers can process events asynchronously, recover after downtime, and replay events when needed. New consumers can subscribe to the same events without changing the producer. Key characteristics of loosely coupled systems:- Independence: services can be developed, deployed, and scaled independently. Producers do not need to know the identity of consumers.
- Reusability: one published event can be consumed by multiple systems (fraud detection, auditing, metrics) without modifying the producer.
- Fault isolation: consumer failures do not block producers; messages remain durable until processed.
- Flexibility and scalability: consumers can be scaled or replaced independently; new consumers are easy to add.
Quick comparison
| Aspect | Tightly coupled | Loosely coupled (event-driven) |
|---|---|---|
| Communication | Synchronous, direct | Asynchronous, via message bus |
| Failure impact | High — failures cascade | Lower — messages persisted, consumers can retry |
| Flexibility | Low — producer must know consumers | High — producers publish events only |
| Scaling | Harder — coordinated | Easier — scale consumers independently |
| Use case | Immediate decision required | Auditing, analytics, decoupled workflows |
When to choose which
- Choose tight coupling when:
- You require immediate results and cannot proceed without the downstream response.
- Latency constraints force a synchronous flow and the downstream service is highly available.
- Choose loose coupling when:
- You need scalability, resilience, and independent evolution of services.
- You want multiple consumers for the same event (analytics, audit logs, monitoring).
- You need durable, replayable events and fault isolation.
What is the central message bus?
Common implementations of the central messaging layer include:- Cloud Pub/Sub — fully managed, scalable message bus on Google Cloud: https://cloud.google.com/pubsub
- Apache Kafka — high-throughput distributed event streaming platform: https://kafka.apache.org/
- Confluent Platform — enterprise Kafka distribution and tooling: https://www.confluent.io/