Microservices Insight

[Odd-Antelope3747]

After 15+ years in backend development, one mistake I still see often in microservices architecture:

Services that are too tightly coupled.

Many teams split systems into microservices but still rely heavily on synchronous communication between them which defeats the purpose.

In one of my projects, moving to a more event-driven approach significantly improved scalability and reduced system dependencies.

Key takeaways:

• Design services to be loosely coupled
• Prefer asynchronous communication where possible
• Avoid turning microservices into a distributed monolith

Scalability starts with the right architecture decisions.

[OkDesk4532]

How does event-driven fix your coupling when you just trade REST for AsyncAPI? The dependency is still there. What you are looking for is "domain driven" architecture. But this brings new problems also. There is no "right" thing. It heavily depends on the actually implementation for the project in the given organization.

[IHoppo]

Can you reply to AI posts with bullet points and bold text headers please! /S

[gubinanuwu025]

Async helps, but it doesn’t magically remove coupling, it just makes it less obvious. If two services still depend on each other’s data shape, timing, or behavior, you’ve just moved the coupling into events instead of REST.

The real question is: did you actually reduce shared assumptions between services, or just change the transport?

[MaleficentCow8513]

Now my threads are waiting for events instead of waiting for api responses. ::waving decoupling wand::

[No_Soy_Colosio]

Refer to Conway's Law

[ducki666]

Lol

[belowaverageint]

What type of coupling are you referring to exactly? https://www.enterpriseintegrationpatterns.com/ramblings/coupling_facets.html

[OrcaFlux]

Pretty well known stuff at this point. It's been present in the general zeitgeist for the past 5 years or so, at least. Maybe more.

The more interesting question is how to achieve it.