Should we choose a monolith or microservices?

Start with a modular monolith: one deployable application split into modules with clear boundaries. Split a module into its own service only when it has a different scaling, failure, team or compliance need. Microservices add network calls, deployments and monitoring that a small team has to pay for every day.

How much does software architecture cost?

The design work is a small share of the build: our initial assessment of architecture and risks typically takes one to two weeks for a new product. The expensive part is changing a poor architecture later, when every new feature touches many parts of the system.

When should we refactor or split the system?

When a change that should be small touches many modules, when one part of the system needs to scale or fail independently, or when several teams block each other in the same codebase. Refactor before the next feature, not after.

What does IEC 62304 require of the architecture?

For software safety class B and C, IEC 62304:2006+A1:2015 clause 5.3 requires a documented architecture that identifies the software items and their interfaces, and verification of that architecture. For class C, any segregation between software items that is needed for risk control must also be identified.

Choosing software architecture: monolith or microservices?

To choose the right software architecture, start with the simplest structure that can work, usually a modular monolith, and move a part of the system into its own service only when a measured need demands it. That need is a different scaling pattern, a failure that must be isolated, teams that block each other, or a compliance boundary. Security, observability and traceability are designed in from day one, because they are expensive to bolt on later.

This guide is for founders, product owners and CTOs who have to make or approve that choice. It draws on our experience at bon.do when we build backends for medical devices, health apps and SaaS products, and when we take over systems that other vendors started.

What is software architecture, and why is it a business decision?

Software architecture is how a system is divided into parts, how those parts talk to each other and where the data lives. It decides how quickly you can change the product, what it costs to run, how it fails and how easy it is to pass an audit.

Architecture affects the business in four areas:

Speed of change. Can a new requirement be delivered in a sprint, or does it touch five modules?
Running cost. Hosting, monitoring and the people needed to operate it.
Risk. What happens when a component or a cloud region fails.
Compliance. Whether you can show an auditor who changed what, when and why.

That is why architecture should not be left to one developer’s favourite stack. It has to follow the product roadmap, the size of the team and the rules the product must meet. A system that handles clinical data has different needs from an internal reporting portal.

Monolith, modular monolith or microservices: which should you choose?

For most new products, a modular monolith is the right starting point: one application and one database, divided into modules with strict boundaries. Microservices pay off when several teams need to release independently or when parts of the system have clearly different load, failure or compliance needs.

	Monolith	Modular monolith	Microservices
Deployment	One unit	One unit	Many independent units
Internal boundaries	Often blurred	Strict modules, one owner each	Network boundaries
Operational load	Low	Low	High: networking, tracing, many pipelines
Data consistency	Simple transactions	Simple transactions	Distributed, often eventual consistency
Good fit	Prototypes, small tools	Most new products and small teams	Several teams, very different load or isolation needs
Main risk	Turns into a tangle	Boundaries erode without discipline	Cost and complexity before they are needed

Microservices are a good choice when:

several teams need to develop and deploy without waiting for each other;
one part of the system has a clearly different load pattern, such as sensor ingress or batch processing;
one part has different compliance or isolation requirements.

Microservices are a poor choice when:

the team is small and the operational burden outweighs the benefits;
the boundaries between domains are not yet understood;
monitoring, automated deployment and failure handling are not in place.

A modular monolith with well-defined boundaries keeps the door open. If a module later has to become a service, it is a move, not a rebuild. Serverless functions fit the same logic: they are useful for spiky, event-driven work, but cold starts, platform limits and vendor lock-in make them a poor default for the core of a regulated product.

How do you choose the right architecture? A seven-step method

Choose the architecture from the product, the domain and the non-functional requirements, not from a preferred technology, and record each decision so it can be revisited:

Understand the product. Who uses it, what data does it process, and which rules apply (GDPR, MDR, IEC 62304, customer security requirements)?
Map the domain. Divide it into bounded contexts before you pick technology.
Write down the non-functional requirements. Response times, availability target, data volumes, retention and recovery time. These drive the architecture more than the features do.
Choose the simplest thing that can work. A modular monolith and a relational database go a long way.
Decide what must scale or fail separately. Only the parts that actually have a different need.
Build in security, observability and traceability from the start. It is cheaper than retrofitting.
Record the decisions. Write short architecture decision records (ADRs) covering the context, choice and consequences, and revisit them as the product grows.

How does architecture affect cost?

Architecture drives three costs: the cost to build, the cost to run and the cost to change. The third is usually the largest, because a system where every new requirement touches many modules gets more expensive with every release, whatever it cost to build.

Build cost grows with every extra service, database and integration that has to be developed, tested and deployed. Microservices are not free: they need networking, monitoring, pipelines and people who can operate them.

Running cost depends on how the system uses cloud resources. The levers that matter most:

Right-size from monitoring data, not guesswork, and turn off non-production environments outside working hours.
Commit stable workloads to reserved capacity or savings plans, and keep on-demand pricing for unpredictable load.
Use managed services for databases, queues and storage where the savings in operational effort outweigh the higher unit price.
Watch data transfer, which is often billed when traffic leaves the cloud or crosses regions.
Set budget alerts, because pay-per-use services and autoscaling can turn a traffic spike into a large bill.

We have seen the effect first-hand. When we rebuilt the MindPlus app and backend, the monthly hosting and service cost fell by 98%. The old product had been through several vendors and an expensive hosting setup; the new backend was designed to run without a large operations budget.

How do you scale without overbuilding?

Scale when measurements show you need to, not before. Keep the application stateless so it can run as several instances behind a load balancer, and scale a part of the system independently only when its load pattern differs from that of the rest.

Vertical scaling means a bigger machine. It is simple, but it has a ceiling, often needs a restart and gets expensive at the top end.
Horizontal scaling means more instances. It needs stateless application code, with sessions and state in a database, cache or queue.

On Kubernetes, the Horizontal Pod Autoscaler adds or removes instances based on CPU, memory or custom metrics such as queue length. According to the Kubernetes documentation, the Vertical Pod Autoscaler recommends or applies new CPU and memory requests, either by recreating pods or, on clusters that support it, by resizing them in place. Recreating a pod involves a restart, so do this with care for databases and other stateful workloads, where a restart means a failover.

A monthly capacity review is worth more than an architecture built for a load that never arrives.

Which security decisions belong in the architecture?

Security by design means the architecture itself limits what an attacker can reach and what a mistake can break. The core principles are least privilege, defence in depth, secure defaults, a small attack surface and failing safely.

In practice:

Least privilege. Every user, service and integration gets only the access it needs, enforced by role-based access control.
Defence in depth. Network, application, data and identity are protected separately, so protection does not depend on a single control.
Encryption in transit and at rest. TLS everywhere, and encrypted storage for sensitive data.
Secrets out of the code. A secret manager such as Azure Key Vault, not .env files in Git.
A secure supply chain. Pinned and scanned dependencies and a build pipeline you can trust.

The OWASP Top 10:2025 confirms that many of the biggest web risks start in design: broken access control is still first, security misconfiguration is second, software supply chain failures are new at third, and insecure design and logging and alerting failures are on the list too. If you work towards ISO/IEC 27001, Annex A control 8.27 asks you to define and apply secure engineering principles to your architecture, and control 8.25 to build security into the development life cycle. Zero trust is one way to meet that, not a named requirement.

How do you design for reliability and observability?

Assume that every component will fail and design for it. Remove single points of failure where the business case justifies it, and make sure you can see what the system is doing before your users tell you.

Make sure you have:

Metrics: response time, error rate, queue length and the business numbers that matter.
Structured logs with a correlation ID, so one request can be followed across components.
Distributed tracing once there is more than one service.
Alerts only for things someone must act on. Too many alerts and nobody reacts.
Tested backup and restore. A backup that has never been restored is not a backup.

Set the availability target deliberately. 99.9% allows about 8.8 hours of downtime a year; 99.99% allows about 53 minutes. Each extra nine needs more redundancy and automation, so weigh its cost against what downtime actually costs you. For a medical product, also plan what the user sees when a service does not respond: can a clinician carry on, and who is notified?

What changes when the software is regulated?

In life science, medtech and healthcare, the architecture is part of the evidence. Auditors and notified bodies expect to see a documented structure, traced requirements, controlled changes and an audit trail, so these belong in the design from the start.

IEC 62304. For software safety classes B and C, clause 5.3 of IEC 62304:2006+A1:2015 requires a documented architecture that identifies the software items and their interfaces, and verification of that architecture. For class C, segregation needed for risk control must be identified. A second edition of the standard is in preparation; build to the one in force.
Traceability. Every requirement should trace to a design element, a test and a release. Our ISO 13485 guide covers the quality system around it.
Audit trail. According to 21 CFR 11.10(e), FDA Part 11 requires secure, computer-generated, time-stamped audit trails for electronic records, and GxP customers will ask for the same. Who changed what, when and why has to be in the data model, not in a spreadsheet.
Logging and GDPR. Logs often contain personal data. Log what you need, pseudonymise identifiers, set retention periods in line with the storage limitation principle in GDPR Article 5(1)(e), and protect access. ISO/IEC 27001 controls 8.15 (logging) and 8.16 (monitoring) describe the expectations.

A clear domain model with documented interfaces is easier to validate than a system where everything depends on everything. Two of our projects show how requirements, rather than trends, determine the architecture. The backend we built for a CE-marked medical device is one .NET API with SQL Server on Azure, with device management, recordings and quality control as part of the same backend. The Wear & Care platform receives continuous sensor data and sends alarms by push, SMS and SignalR, so it uses message queues and runs in Kubernetes.

When should you refactor or split the system?

Refactor when a change that should be small touches many parts of the system. Split a module into a service when it needs to scale, deploy or fail independently, or when several teams block each other in the same codebase. Do it before the next feature, not after.

Warning signs we look for when we take over a system:

Simple changes need coordinated releases of several parts.
Nobody can say which module owns a piece of data.
Incidents are found by customers, not by monitoring.
Audit questions take weeks to answer because evidence lives outside the system.

What is the next step?

Choose the simplest architecture that lets you deliver the next requirement without breaking existing functionality and that you can explain to a developer, a CTO and an auditor. Start simple, measure, and move the boundaries when there is a reason.

If you are about to start a product or are stuck with one that has become hard to change, book a call. We will look at your requirements and give you a free project assessment with a recommended architecture for the system.