Look, we need to have an awkward conversation.

Most "microservices" platforms aren't actually microservices. They're monoliths wearing a microservices t-shirt.

I know, I know. Everyone claims they're "microservices-based" now. It's the hottest buzzword since "omnichannel" and "headless." But here's what I've learned after years of evaluating these platforms: marketing loves microservices a lot more than engineering does the work to build them properly.

This isn't about any one vendor—it's about how the entire industry has adopted 'microservices' as a marketing term without the underlying commitment to the architecture.

This matters because if you choose a platform based on fake microservices, you'll end up with the exact problems you were trying to escape: vendor lock-in, painful upgrades, limited customization, and the inability to actually scale.

So let's talk about what real microservices actually look like, and how to spot the impostors.

What Makes Microservices Actually "Micro"?

True microservices architecture isn't complicated to define. It has five characteristics that aren't negotiable:

1. You can deploy them independently

If you can't update your pricing service without touching cart, checkout, and inventory, they're not independent services. Full stop.

Real microservices: "We're pushing a pricing fix to production. It'll be live in 5 minutes. No other services affected."

Fake microservices: "We need to schedule a maintenance window. We'll deploy pricing, but we have to redeploy everything and do full regression testing."

2. Each service owns its data

Data isolation. No common database tables. Each microservice manages its own data lifecycle.

Real microservices: The Cart service has its data. Inventory service has its data. They talk via APIs, never through shared data.

Fake microservices: "Our services are totally decoupled! They just all connect to the same data because... performance."

3. They're loosely coupled

Changes to one service's internals don't break other services. They communicate through well-defined API contracts.

Real microservices: You can completely rewrite how pricing works internally, and as long as the API contract stays the same, nothing else cares.

Fake microservices: "You can customize pricing! Just make sure you also update these six other services to match your changes."

4. One service, one job

Each microservice handles a specific business capability. Clear boundaries, single responsibility.

Real microservices: Pricing service handles pricing. The promotions service handles promotions. Cart service handles carts. Simple.

Fake microservices: "Our commerce service handles products, pricing, promotions, inventory, orders, and checkout. But it has APIs, so it's definitely microservices!"

5. Technology freedom

Different services can use different tech stacks based on what makes sense for that specific problem.

Real microservices: Search uses one type of technology. Core services use another. Whatever works best.

Fake microservices: "You have complete technology freedom! As long as you use our entire proprietary framework."

The Usual Suspects: Common "Fake Microservices" Patterns

Here are the patterns we see constantly:

The Modular Monolith

This is the most common one. The platform has internal modules that are separated in code, but they all deploy together, share a database, and have tight dependencies.

The pitch: "We have a highly modular architecture with dozens of services!"

The reality: Those "services" all ship in the same package. One version number. One deployment. It's a well-organized monolith, which is fine—just don't call it microservices.

Red flags:

• Everything deploys together
• One version number for everything
• Can't run services separately

Why it hurts: Synchronized releases, version compatibility nightmares, and you can't scale the parts that need it without scaling everything.

The API-First Monolith

A traditional monolith that got retrofitted with an API layer. The frontend is decoupled (headless!), but the backend is still one big system.

The pitch: "We're API-first and headless! Modern architecture!"

The reality: Having good APIs doesn't make you microservices. Even a well-designed monolith can have excellent APIs.

Red flags:

• Can't swap individual components
• Platform upgrades mean upgrading everything
• Your custom extensions break with every major update

Why it hurts: You get headless benefits on the frontend, but you're still locked into monolithic backend constraints.

The Distributed Monolith

Services that are technically separate processes, but so tightly coupled they might as well be one system. You can't change one without coordinating changes across all of them.

The pitch: "Everything is a separate service!"

The reality: If you need to deploy 12 services simultaneously to ship one feature, you've built a distributed monolith.

Red flags:

• Shared data across services
• Breaking API changes require coordinated updates across everything
• "Big bang" releases are the norm

Why it hurts: All the complexity of distributed systems, none of the benefits of real microservices. Worst of both worlds.

The Service Count Game

Some vendors inflate their microservices count by labeling every API endpoint or internal module as a "microservice."

The pitch: "We have 100+ microservices!"

The reality: One actual microservice might expose 20 endpoints. They're counting endpoints, not services.

How to check: Ask how many independently deployable units they have. Watch the number drop from 100+ to... maybe 5.

Why it hurts: It's misleading marketing that makes fair comparisons impossible.

The Questions That Expose Fake Microservices

Here's how I evaluate platforms. Ask these questions and watch for hesitation:

Can I deploy the pricing service without touching anything else?

Real answer: "Yes, completely independently."
Fake answer: "Well, you'd want to deploy everything to ensure compatibility..."

Can I run different service versions in production simultaneously?

Real answer: "Absolutely. That's why we have API contracts."
Fake answer: "All services need to be on the same version."

Can I replace one service with my own implementation?

Real answer: "Sure, as long as you implement the API contract."
Fake answer: "Our services are tightly integrated for optimal performance..."

If your pricing service goes down, does checkout still work?

Real answer: "Checkout would degrade gracefully—maybe show cached prices or prevent purchase until pricing is back."
Fake answer: "The whole platform would be unavailable."

If you're getting the "fake" answers, you're not looking at real microservices.

Why This Actually Matters

You might think I'm being pedantic. Does it really matter if they're "true" microservices if the platform works?

Short answer: Yes, it matters a lot.

Here's what happens when you buy fake microservices:

You're locked in. Can't swap components, can't migrate gradually, can't adopt best-of-breed solutions. Same vendor lock-in as monoliths.

Upgrades are painful. Instead of updating one service at a time, you're doing big bang upgrades that require months of testing and often break your customizations.

Customization is limited. True microservices let you extend or replace individual services. Fake microservices force you into the vendor's constraints.

Scaling is expensive. True microservices scale what needs scaling. Fake microservices make you scale everything, even the quiet parts, driving up infrastructure costs.

You're stuck. True microservices let you adopt new tech incrementally. Fake microservices lock you into the vendor's roadmap.

How We Built Broadleaf Differently

We built Broadleaf as true microservices from the beginning because we've lived through the pain of monoliths disguised as microservices.

Each of our 30+ services is independently deployable. Want to update pricing? Update the pricing service. That's it. Nothing else moves.

Every service owns its data. No shared schemas.

You can deploy them your way. Start with everything bundled together (easier to manage), then split out services as you scale. That's what our Flex Package deployment is for.

You get the source code. We're source-available for licensed customers. You can look under the hood and verify everything I'm saying. No "trust us" required.

You can add your own services. Ours are Java/Spring, but you can write services in whatever makes sense for your use case. They're truly independent.

This isn't marketing. Its architecture you can inspect and verify yourself.

The Checklist

Save this for your next platform evaluation:

Must-Have Answers: "Yes" or Walk Away

☐ Can I deploy individual services independently?

☐ Can I run services at different versions simultaneously?

☐ Can services fail independently without taking down the system?

☐ Can I scale individual services based on their load?

☐ Can I replace one service without modifying others?

Red Flags: "No" Means Not Real Microservices

❌ "All services deploy together for consistency"

❌ "Services share the same data for performance."

❌ "You need to coordinate service updates."

❌ "Platform updates require full system testing"

❌ "Everything must use our framework."

Look, Here's the Thing

Every vendor is going to tell you they're "microservices-based" now. It's table stakes marketing.

But words are cheap. Architecture is expensive.

The next time someone claims microservices, ask the hard questions. Get technical. Request proof. Test it yourself if you can.

Because choosing a platform based on fake microservices means you'll spend the next 3-5 years dealing with the same monolithic problems you were trying to escape, except now with more complexity and a fancier buzzword.

True microservices give you freedom—to customize, to scale, to evolve, to own your tech stack.

Fake microservices give you the same vendor lock-in, just with better marketing.

Choose carefully.

Want to verify this yourself? We offer free developer access where you can run our services locally, inspect the code, and verify every claim.