It was 2014. Paraná, Argentina. A free period at school, the World Cup just around the corner, and a group of friends who — with not much else to do — started talking about football.
At some point someone threw out the idea: what if we compete to see who actually knows more? The rules were simple. Everyone made their predictions before each match — exact score, winner, points. Three points if you nailed the exact result. One if you only got the winner right. Zero if you missed entirely.
What wasn't simple was what it created. Suddenly you found yourself watching matches you normally wouldn't care about — but now they mattered, because your prediction depended on them. There were laughs, arguments, jokes, small symbolic bets. And that hard-to-describe feeling of desperately wanting the game to end exactly the way you'd predicted.
We repeated it across Copa Américas, Euros, and other tournaments. Each time, the game was the same. And each time, it was worth it.
But years pass. Life changes. I ended up living on a different continent, far from many of those friends. And even though technology keeps us connected, it's not that easy to recreate that spontaneous dynamic we had when we were all together at school.
That was the starting point for this project.
A simple project… with a complicated decision
The idea was clear: build a small app that would let us play again. A place where everyone could submit their predictions, check the results, and follow an updated leaderboard.
Functionally, it's not complex. Any developer with some experience could build this in a weekend — a monolith, a database, done. That's the sensible choice. No question.
I didn't do that.
I decided to build it using a microservices architecture. Not because the project needed it. But because I did.
The gap between knowing and understanding
There's a reality many developers will recognize: there are technologies and architectures we hear about constantly — in articles, talks, conferences — but that we rarely get the chance to practice in any real depth.
Microservices are one of those cases. There's no shortage of content about them. Their advantages, their drawbacks, when to use them, when to avoid them. But there's an enormous gap between understanding a concept in theory and actually facing the real problems that surface when you implement it.
Reading about distributed systems is not the same as building one. Even a small one.
So I made a conscious decision to use this project as a learning lab. I knew exactly what I was doing: adding unnecessary complexity for an MVP, taking longer than I should, and exposing myself to problems that simply wouldn't exist in a monolith.
That's precisely why I did it.
What this kind of architecture forces you to think about
Designing the system this way wasn't just a theoretical exercise. Every architectural decision came with concrete questions I had to work through:
Real problems that came up
- How do you separate responsibilities without services becoming tightly coupled?
- How do you handle communication between services without creating a tangle of synchronous calls?
- What happens when one service fails and others depend on it?
- How do you deploy parts of the system independently without breaking everything else?
- How do you reliably integrate an external sports results API across service boundaries?
Each of those problems is a piece of the puzzle that distributed systems really are. And even though my project is small, confronting those challenges gave me a much deeper understanding of how these architectures actually work in practice.
It wasn't the easiest path. But it was the most interesting one.
Where this is going
The project is close to its first working version. The goal is to have it ready before the next World Cup — using some league matches as a test run — so we can do what we used to do years ago: compete against each other, laugh at the predictions that aged poorly, and celebrate when someone calls an unlikely result.
In the next articles I'll dig into the concrete technical decisions: which services I defined, how they communicate, which tools I chose and why. But this first piece was necessary to set up something that technical blogs often skip: the personal why behind a technical decision.
A thought for anyone considering something similar
In software development, there's a lot of talk about avoiding overengineering. And in most cases, that advice is right — especially in professional contexts where time and resources matter.
But side projects have a huge advantage: they don't always have to optimize for speed of delivery or efficiency. Sometimes they can optimize for something more important: learning.
Building something that forces you out of your comfort zone, exploring technologies you don't get to touch in your day job, and wrestling with problems you don't yet know how to solve — that has a kind of value that no tutorial can give you.
And if that project is also connected to something personal — memories, friends, something that matters to you beyond the code — then the process becomes even more meaningful.
"Sometimes the best reason to build something isn't that it's the most efficient solution. It's that, in the process of building it, you'll learn something you couldn't have learned any other way."
Top comments (0)