GDG - DevFest Beirut
Microservices: The Power of Breaking Down to Build Up
Lebanese American University, Beirut, Lebanon2025
At GDG DevFest Beirut 2025 I walked through the road from a monolith to microservices: when the move is worth it, how split services talk and scale, and what the switch really costs. The goal was to help people make that call, not to sell them on it.
- Start with a modular monolith. For a new product it is the right default.
- Break out only the part under real pressure, like Search, so it can ship and scale on its own.
- Split services own their data, talk through events, and scale out only where the load is.
- Microservices are a cost you pay when scale demands it, not before.
Start with a monolith
Mobile and web clients talk to one application backed by one database: a single stack, a single deployment, and easy debugging because everything runs in one place. For a new product this is the right default. The real downside shows up later, when changing anything safely means understanding the whole system, and splitting naively makes it worse: if clients call every service directly, each one has to handle auth, rate limiting, and errors on its own, which is why a gateway belongs in front.
When to break something out
I keep the monolith modular, with products, shops, reviews, payments, riders, orders, and users each behind clear boundaries, and pull out only Search. The reason is load: Search takes far more traffic than the rest, so as its own service it can be developed, deployed, and scaled independently without dragging everything else along.
How services talk and scale
Each service owns its data, and the stores do not have to match: MongoDB in one place, Postgres in another, Elasticsearch for search. You lose cross-service joins, so instead of calling each other, services publish events to a stream that consumers read independently; a new consumer can be added without touching the producer, and a slow one blocks no one. For load, scaling up with a bigger machine is simple but hits a ceiling, while scaling out runs more copies of only the service under pressure, which is where splitting pays off.
What microservices cost you
Every service is something to orchestrate, monitor, and debug across network boundaries. You need a bigger team, the infrastructure costs more, and deployments get complicated. That is why microservices are not ideal for an MVP: they are a cost you pay when the scale demands it, not before.