Recently, I was working on a backend feature. To get the required data, I had to call a REST API from another microservice. I finished the implementation, ran the unit tests, everything passed. I moved on.
The next day, the same unit test failed.
I checked the logs and saw this:
503 Service Unavailable , “no healthy upstream.”
Basically, the service I was calling was down. Probably something related to load balancing or proxy issues. But the real problem was simple (not actually simple),
I was blocked because another service was not healthy. And I had a deadline.
The Problem
When another microservice goes down, your code can be perfect, but it still won’t work.
You can’t move forward. You start waiting. You send messages. You wait again. Not a good place to be when time is limited.
The Simple Solution
I didn’t invent anything new. I didn’t design some complex fallback system. I just set up a mock server. That’s it.
What is a Mock Server?
A mock server acts like the real API.
If the API contract is already finalized, you can configure a mock server to return the expected response. It behaves like the real service, but you control it.
So instead of waiting for DevOps or another team to fix the upstream service (like me), I pointed my backend to the mock server. And everything worked again.
It’s actually the same idea we use in unit testing, we mock dependencies. This is just applying the same concept at the API level.
Setting It Up
Honestly, I thought it would take time.
But it didn’t.
Most API tools like Postman or Hoppscotch allow you to create a mock server in just a few steps. I tested both. Very straightforward.
No complex setup. No heavy configuration. Sometimes we assume something will be hard, but it’s not.
I found clear 7 min video from youtube and I will put it down.
What I Realized
At first, I thought my only option was to wait until the service came back online.
But that’s not always necessary.
If the API contract is defined and stable, we can use a mock server to bridge the gap between frontend and backend.
Frontend doesn’t need to wait. Backend doesn’t need to wait. Everyone keeps moving.
That means faster delivery and fewer blockers.
Final Thought
In real world engineering, many problems feel big in the moment. But often, the solution is simple. For me, this time, it was just setting up a mock server and refusing to wait for “no healthy upstream” again.
Resources
youtube link » https://youtu.be/Ef3RvRpY9Co?si=N0mWg23qwLApv4na