Architecture Choice Guide

Architecture choices are tradeoffs. A monolith, modular monolith, and microservices architecture can all be good choices in the right context. The job is to match the structure to the product, team, domain, and operational maturity.

This guide brings together the earlier architecture lessons so you can reason about the choice instead of treating one style as automatically better.

Start With The Problem

Before choosing an architecture, ask what problem you are trying to solve.

If the problem is messy code, unclear boundaries, and controllers doing too much, microservices will not fix that by themselves. They may spread the mess across multiple deployable applications.

If the problem is that one team cannot safely change billing without breaking courses, a modular monolith may help by creating clearer boundaries inside the same deployment.

If the problem is that several teams need independent ownership, scaling, deployment, and data boundaries, microservices may be worth the cost.

Choose A Monolith When Simplicity Matters

A monolith is often the right starting point for a PHP application.

Choose a monolith when:

• the team is small
• the domain is still changing quickly
• one deployment is acceptable
• operational simplicity matters
• the application can scale as one unit for now
• local development should stay straightforward

A monolith can still have good internal design. It can use controllers, services, repositories, domain objects, tests, queues, and clean boundaries.

The risk is that the codebase becomes a big ball of mud if boundaries are ignored. The answer is not automatically microservices. The first answer is usually better structure inside the monolith.

Choose A Modular Monolith When Boundaries Matter

A modular monolith keeps one deployment but organises code around business capabilities.

Choose a modular monolith when:

• the application has distinct areas such as billing, courses, users, and reporting
• changes in one area keep affecting another
• developers need clearer ownership
• a single deployment is still acceptable
• the team is not ready to operate many services
• you may want the option to extract a service later

A modular monolith is a strong default for many serious PHP applications. It gives you clearer boundaries without forcing network calls, distributed tracing, multiple databases, and independent deployments.

The risk is pretending folders are boundaries while modules still freely query each other's tables and use each other's internals. Boundaries need rules, reviews, tests, and sometimes tooling.

Choose Microservices When Independence Is Worth The Cost

Microservices are separate applications that communicate over network boundaries.

Choose microservices when:

• teams need independent deployment
• different parts of the system scale very differently
• the domain boundaries are well understood
• services can own their data
• the organisation can monitor and operate multiple services
• failure handling, retries, timeouts, and observability are mature enough

Microservices can be excellent when the organisation earns them. They can also be expensive when introduced too early.

The risk is a distributed monolith: many services that must deploy together, share databases, call each other synchronously for every request, and fail in chains.

A Practical Decision Table

Use this as a first pass, not a rulebook.

Small team, changing product, simple operations:
  Start with a monolith.

Growing product, clear business areas, one deployment still acceptable:
  Prefer a modular monolith.

Multiple teams, independent deployment needed, strong operations:
  Consider microservices.

Messy code, weak tests, unclear ownership:
  Improve boundaries before splitting services.

One slow feature with different scaling needs:
  Consider isolating that capability only after measuring the problem.

Architecture should be justified by constraints. "Microservices are modern" is not a constraint. "Billing must deploy independently because checkout releases are blocked twice a week" is a constraint.

Questions To Ask In A Review

When reviewing an architecture proposal, ask:

• What specific problem does this choice solve?
• What new complexity does it introduce?
• Who owns each boundary?
• Where does the data live?
• What happens when a dependency is unavailable?
• How will developers run this locally?
• How will logs, metrics, traces, and errors be followed?
• What tests prove the important flows still work?
• What would make us reverse or revisit the decision?

Good architecture decisions include tradeoffs. If a proposal lists only benefits, it is incomplete.

Junior-Level Contribution

As a junior developer, you may not be the person making the final architecture call, but you can still contribute well.

You can notice when a controller is doing too much. You can ask whether a class belongs in billing or courses. You can avoid direct cross-module database queries. You can make service calls handle timeouts. You can write small tests around boundaries. You can document the reason for a decision in plain English.

Those habits matter more than using impressive architecture vocabulary.

What You Should Be Able To Do

After this lesson, you should be able to compare monoliths, modular monoliths, and microservices in terms of deployment, ownership, data boundaries, operational cost, and failure modes.

For junior work, the practical skill is choosing the simplest architecture that solves the actual problem while leaving the codebase easier to change next month.