Microservices vs Monoliths for a Medium‑Sized Print On Demand Business

For years, “microservices” has been the fashionable architectural choice. I know, because I built our original system that way. At the time, it made perfect sense: we were growing fast, our processes were evolving weekly, and we needed the freedom to deploy changes without risking the entire operation.

But businesses change. Ours certainly has. And the architecture that once felt liberating now feels… misaligned. Not broken. Not obsolete. Just no longer the best fit for the shape of the business we’ve become.

This article is a reflection on that journey - what microservices gave us, what they cost us, and why a Laravel‑based monolith (or at least a more consolidated architecture) is starting to look like the right next step.

Why We Built Microservices in the First Place

When we started, the business was:

• moving quickly
• experimenting constantly
• adding new workflows every few months
• small enough that “deploy everything at once” was a real risk
• operationally chaotic in a way that made isolation attractive

Microservices solved real problems:

• We could deploy one service without touching the others.
• We could rewrite or replace parts of the system without a full migration.
• We could scale individual components independently.
• We could turn off parts of the system temporarily with zero impact.

For a growing Print‑on‑Demand business, that flexibility was gold.

And Laravel made it easy to build small(ish), focused services - each with its own API, its own logic, its own release cycle.

How the Business Has Changed

Fast‑forward a few years, and the business is no longer the same organism.

• Processes have stabilised.
• Throughput is predictable.
• The “move fast and break things” phase is over.
• Operational reliability matters more than architectural purity.
• The team is larger, but not large enough to run a platform‑engineering function.

And the system we built - the one that matched the business perfectly at the time — now fits like a suit tailored for a younger version of ourselves.

We’ve ended up writing configuration workarounds to compensate for architectural drift:

• pallet definitions
• position mapping
• bulk‑update tools for users
• cross‑service synchronisation scripts

These aren’t signs of failure. They’re signs of a system doing its best to keep up with a business that has outgrown its original shape.

The Cons: Where Microservices Hurt Us Now

1. Data is fragmented across multiple services

Each service owns its own data, which is great in theory. In practice, it means:

• reporting is harder
• cross‑service queries require stitching
• debugging requires jumping between systems
• consistency is a constant negotiation

2. Some updates require coordination

The dream of “independent deploys” fades when a workflow spans five services. A simple change can require:

• schema updates in multiple places
• API versioning
• careful rollout sequencing

3. Several frontends, several mental models

Each service has its own UI or admin panel. That means:

• more places for users to look
• more places for bugs to hide
• more cognitive load for the team

The architecture is clean. The experience is not.

The Pros: What Still Works Beautifully

1. We can turn parts of the system off temporarily

If a service misbehaves, we can isolate it without taking down the whole operation. For a production floor that runs all day, that’s a real advantage.

2. We can release updates independently and quickly

A small fix to a single workflow doesn’t require a full‑system deployment. That’s still a huge win.

3. Laravel makes microservices pleasant - up to a point

Laravel’s ecosystem, tooling, and conventions make it easy to build small, focused services. But the more services you have, the more you multiply:

• auth
• logging
• monitoring
• deployments
• shared logic
• shared models

Laravel helps, but it doesn’t eliminate the overhead.

Where This Is Heading

This is the pivot point: the architecture hasn’t failed. It has simply stopped matching the business.

A medium‑sized Print‑on‑Demand company doesn’t need a Netflix‑style microservice ecosystem. It needs:

• reliability
• clarity
• maintainability
• predictable deployments
• a single source of truth for data

I'm currently reviewing how we actually get there. It might be a unified frontend - giving our users the mirage that there is "one system", whereas in fact there are still many.