r/microservices

Hey,

I am working on a microservice project which have 4 services at this point. Now as per the requirement i have a need to implement service call hierarchy as -

client -> service A -> service B -> service C

i am not feeling much confidence in this as i think the compensation for failure will be a mess (SAGA & i m not using event-driven as of now). Can someone guide me on this and tell the better & standard way to do this. should i implement - service A -> service B & on success service A -> service C instead?

Appreciate if someone can share their knowledge on this.

Thanks!!

I hear scaling operations between teams on the same project is one of the strongest incentives for going into a microservice architecture.

I was wondering what everyone’s experience was on how true this was? Did you find that you started microservices but you still had to orchestrate deployments with consumers?

What other strategies are out there for solving for team operations without distributed systems.

I was even playing with an idea of the server compiler crashing when someone changed an api route that doesn’t belong to them, and a separate mechanism to lock down what api route can write data to a specific table and would also crash when others violated this.

Anyone ever explored programmatically enforced guard rails that might not be split up the project? Or is that really the most sound way to go about this.

EDIT: server compiler meaning a framework as the server or such. Imagine nextjs npm run dev, but it crashes with an error you’re not allowed to change this api route.

I've been building modular systems for years and kept hitting the same wall: teams either stay in a monolith too long because extraction is too painful, or they go microservices too early and pay the operational cost before they need to.

The root cause I kept finding: the architecture itself doesn't support the transition. Extracting a module requires refactoring, not just redeployment.

So I formalized what I'd been converging on: the Pyramid Architecture. The central mechanism is a pre-engineered migration seam at the service interface level — so moving a module from local to remote is a manifest change, not a code change.

The pattern has four faces:

- Structure: vertical (business modules) × horizontal (layers), enforced at build time via sub-project dependencies

- Interaction: extensions as active orchestrators + pluggable drivers (closer to but distinct from Hexagonal ports/adapters)

- Elasticity: the M/P model — M modules across P processes, same code at any point on the spectrum

- Convergence: this one surprised me — clean typed facades + observable lifecycle events + audit trails turn out to be exactly what LLM agents need. AI-first as an emergent property of cleanliness, not a design goal.

The hardest trade-off is cross-module consistency — transactions are scoped to a single module by design, cross-module consistency is handled via an interceptor-based saga pattern. Not ACID, but neither is any honest microservices architecture. Validated across real ERP platforms — 230+ business modules, JPA + MongoDB, multitenancy.

Whitepaper + repo: https://github.com/thevpc/the-pyramid-architecture

Curious whether anyone has tackled the monolith/microservices transition differently — especially the consistency problem.

https://preview.redd.it/2fba903fpkzg1.png?width=1664&format=png&auto=webp&s=327537153db20b68df95a9237124625331922784

I’ve been thinking a lot about workflow orchestration in distributed systems.

A common pattern I keep seeing:

A team starts with simple HTTP calls between services.

Then they need:

• retries
• compensation
• callbacks
• timeouts
• observability
• partial failure handling
• long-running operations

Eventually, someone says: "we need a workflow platform."

Sometimes that is true.

But sometimes the platform becomes bigger than the problem.

My argument is that many teams don’t need a full workflow platform at first. They need a durable orchestration layer that speaks the same language their systems already speak: HTTP.

That is the direction I’ve been exploring with Trama: orchestration as an API, not as a new programming model everyone has to adopt.

The goal is not to replace every workflow engine.

The goal is to cover the large middle ground between:

• "just call another service"
• and "adopt Temporal/Cadence/Airflow/etc."

Curious how people here think about this tradeoff.

When does orchestration justify a full platform, and when is that overkill?

Hey everyone,
For those of you building backends that connect to multiple external systems (different APIs, databases, message queues, storage, notifications, LLMs, etc.), I have a real question:
Is the setup and ongoing maintenance actually painful for you?
I know there are always workarounds: custom wrappers, internal libs, raw HTTP clients, etc. But I’m curious:
When you’re wiring up yet another API or swapping providers, do you feel the friction of inconsistent patterns, repeated boilerplate (retries, logging, auth, error handling, env configs), secret sprawl, and brittle multi-step flows? Or is it honestly not that big of a deal in practice?
I’m working on a project in this space and I’m trying to get a honest read from engineers on how much this actually sucks day-to-day. Would a more consistent, unified way of talking to all these components be genuinely useful, or are most teams fine managing the zoo of SDKs?
Appreciate any war stories or straight opinions, especially from people running moderately complex backends. Thanks

The auth service is working perfectly on its independent api

But when I connect it to the api gateway it gives a 404 error I have tried everything and changed the application.properties multiple times but no solution.The spring version is 4.0.6 and the cloud version is 2025.1.1

Help me please