When I started building ProdeMaster, I told myself something that I now find almost funny: "this next service is going to be easy — I already did this."
I was wrong. And I'm really glad I was.
A quick recap of where we are
If you're following this series, you already know that ProdeMaster is a sports prediction app I'm building from scratch — not because I'm launching a startup, but because I wanted a real project to learn real things. Things like microservice architecture, hexagonal design, and all the patterns that never show up in tutorials but live everywhere in production codebases.
So far, the journey has looked something like this:
First came UserService — a straightforward Spring Boot service using the classic MVC pattern. Nothing revolutionary, but a solid foundation. Then I had to figure out Docker and Docker Compose to wire everything together: the Eureka service registry, the API Gateway, the containers, the internal networking. All connected, all talking to each other.
After that, MatchService — and this is where things got genuinely interesting. This is the service responsible for fetching match data and results from an external API (I ended up going with SportMonk after a cost-benefit analysis). For this one, I committed to hexagonal architecture for the first time. Domain, application, infrastructure — clean separation, real scalability. I also introduced Kafka here, which I'd heard of but never touched. Topics, producers, consumers — all new territory.
And now I'm in the middle of building PredictionService.
The pattern I didn't know I needed
Prediction Service lets users make predictions on upcoming matches. On paper, it seemed like familiar ground — hexagonal architecture again, similar patterns, similar structure. I genuinely thought it would feel like repetition.
Then, while talking through the design with my AI coding assistant (which, let's be honest, has been functioning as my senior engineer throughout this project), something came up that I hadn't seen before: the Circuit Breaker pattern.
A Circuit Breaker is a resilience pattern designed to handle failures in distributed systems. When a downstream service starts failing, instead of hammering it with requests until everything crashes, the circuit "opens" — temporarily stopping calls to that service and returning fallback responses. After a timeout, it enters a half-open state to test if the service recovered. If it did, the circuit closes again. If not, it opens back up.
It's widely used in professional microservice environments. It's also — and this is what surprised me — almost never talked about in beginner or intermediate content.
Unlike Kafka, which has a massive ecosystem of tutorials, courses, and documentation aimed at developers at all levels, Circuit Breaker is one of those patterns that seems to exist only in the gaps between what you're taught and what you actually need to know. It's assumed knowledge. And that gap is exactly where I've been living lately.
On knowing what you don't know
I'm not going to tell you I'm now an expert in resilience patterns. I'm not. I'm also not an expert in Kafka, or hexagonal architecture, or microservices in general. I'm someone who is actively figuring out where the edges of their knowledge are — and I think that matters more than any specific thing I've learned.
There's a meaningful difference between not knowing something and not knowing that you don't know it. The first is just a gap. The second is a wall you can't see.
Every time a new pattern surfaces — one I never expected, one nobody warned me about — that wall gets a little smaller. And that's the whole point of building something like this.
If you're learning to develop and you're thinking about building a portfolio project: don't build the same e-commerce app everyone builds. Or do — but twist it. Add a constraint. Follow a pattern you've never used. Let the project take you somewhere you didn't plan to go. The learning doesn't live in the thing you build. It lives in the gap between what you thought you knew and what the project actually asked of you.
Build toward that gap. That's where the good stuff is.
Top comments (0)