I still remember the panic call at 2 AM from our DevOps team back in 2019. Our monolithic e-commerce platform serving the Southeast Asian market had a payment processing bug. The entire system went down for four hours. Four. Hours. We lost roughly $200K in transactions across Vietnam, Thailand, and Indonesia. That's when I realized: we weren't just building software anymore. We were building infrastructure that directly impacted people's ability to buy things.
Fast forward to today, and that same company now runs on microservices. The payment service can fail independently without bringing down product catalogs or user accounts. But here's what nobody tells you when they're selling you on microservices: it's not a silver bullet. It's a tradeoff that makes sense at a certain scale, and there's a specific moment when you should make the leap.
The Real Problem with Monoliths
Let me be honest—monoliths aren't evil. They're just... limited. When you're building something new, they're actually great. Simple to deploy, easier to debug, and your entire codebase can fit in your head. GitHub's monorepo serves millions of requests daily. Shopify started as a monolith. The issue emerges when you grow.
In Vietnam's booming e-commerce market, we've seen this pattern repeat: startups like Tiki and Shopee started with tight codebases. But as they scaled to handle peak traffic during Tet sales (2–3x normal volume), the monolith became a bottleneck. You can't scale individual features independently. Need to add cache servers for product search? You're deploying the entire system. One bad deployment affects everything.
The metrics that matter: if your monolith team is deploying once a day and your time-to-fix is measured in hours, you're feeling the pain. Microservices won't cure bad engineering practices, but they do remove a specific kind of friction.
So What Actually Is a Microservice?
It's aggressively simple: a microservice is a small, independently deployable piece of your system that owns one business capability. Not one function. One capability.
People get this wrong constantly. They think "microservice" means tiny. I've seen shops with 47 microservices handling 6 business domains. That's not distributed systems thinking—that's just overengineering with network calls.
Share this post
Related Posts
Need technology consulting?
The Idflow team is always ready to support your digital transformation journey.
The litmus test I use: if your service can't be rewritten in a week by a single engineer without breaking others, it's too coupled. If it handles three unrelated business problems, it's too fat.
Real examples:
- Payment service: handles transactions, refunds, settlement. One team owns it.
- Inventory service: stock levels, reservations, fulfillment logic. Owned by ops/warehouse folks.
- User service: auth, profiles, preferences. Owned by platform team.
Each talks to others via APIs or message queues. Each can be deployed, scaled, and replaced independently.
The Infrastructure Tax Nobody Mentions
Here's what keeps me up at night: microservices are infrastructure-expensive. You need:
Service discovery: How does payment service find inventory service when it runs 47 instances across three regions? Consul, Kubernetes, or similar.
Observability: With a monolith, one log aggregator works. With 50 services, you're looking at $200K+/year for Datadog or equivalent. This is real money.
Network resilience: Monoliths have in-process function calls. Microservices have network calls, which fail. You need circuit breakers (like Hystrix or Resilience4j). One failed payment service shouldn't cascade to kill orders.
Testing complexity: You can't just unit test anymore. You need contract testing between services, integration testing, and chaos engineering to ensure resilience.
Vietnamese startups I've advised often skip this investment. They deploy microservices but without proper monitoring, and then wonder why debugging production issues takes 6 hours instead of 30 minutes.
The sweet spot I've observed: microservices make sense when your organization has 30+ engineers across multiple teams. Below that, you're probably burning time on infrastructure instead of features.
When Microservices Actually Won. And Lost.
Netflix is the textbook case everyone cites. They pioneered this in 2008–2009 because AWS went down (remember the viral "Welcome to the Simian Army"?). They needed to decouple services so a recommendation service outage didn't kill video playback. Smart move. They had the infrastructure budget.
But I also watched an agency in Ho Chi Minh City implement microservices for a logistics platform with 6 engineers. Three months later, they gave up. The overhead of managing Docker, Kubernetes, service meshes, and distributed tracing consumed more engineering time than building features. They went back to a monolith with database sharding and caching. Sometimes boring wins.
The Hidden Complexity
Two things experienced teams struggle with:
Eventual consistency: In a monolith, you can wrap things in a transaction. User signs up, create profile, assign role, send email—atomic. In microservices? User service creates the profile, then emits an event. Auth service consumes it. Email service consumes it. What if email fails? Now you have a user who can't receive their password reset. You need compensating transactions, dead-letter queues, and retry logic. This is hard.
The distributed transaction problem: Let's say payment fails after inventory is reserved. With a monolith, you rollback. With microservices, you need the payment service to somehow tell the inventory service "hey, undo that reservation." This is the kind of thorny problem that keeps architects awake.
The Vietnam Angle
Southeast Asia has unique constraints. Not every startup has $500K for infrastructure. Internet reliability varies by region. A microservices architecture designed for Silicon Valley won't work as-is in rural Vietnam. You need to think about graceful degradation—if network latency spikes to 2 seconds (which happens), your service-to-service calls will timeout.
Companies like Grab and Gojek handle this by building with regional isolation. Their services are deployed closer to users, and they cache aggressively. It's microservices, but adapted for the market.
So Should You Do It?
Ask yourself:
Do you have 25+ engineers working on unrelated features?
Can you afford $300K+/year in infrastructure and tooling?
Are specific parts of your system bottlenecking your business?
Can your organization handle the operational complexity?
If the answers are mostly yes, microservices unblock you. If not, a well-architected monolith with smart caching and database optimization will serve you better.
At Idflow Technology, we've helped companies in Vietnam and Southeast Asia make this decision. Sometimes we architect microservices, sometimes we optimize the monolith. The tool isn't the point—solving the business problem is.
