ADR: Modular Monolith vs Microservices in a Greenfield Fintech

Every architecture decision is a function of the forces acting on the system at a given moment. Ignoring those forces and applying a pattern because it is "modern" or because the industry reference company uses it is one of the most common ways to accumulate premature technical debt.

In this scenario, the forces are clear and, in part, contradictory:

Business validation speed. The fintech does not yet know exactly what its real bounded contexts are. The payments domain seems obvious, but the boundaries between "account", "wallet", "credit limit", and "transaction" only become clear after multiple iterations with real customers. Defining service boundaries before understanding the domain is the mistake Martin Fowler describes with surgical precision in MonolithFirst: you distribute complexity before understanding it, and refactoring boundaries between microservices is orders of magnitude more costly than moving modules within a monolith.

Team size and capacity. With 4–7 engineers, every engineering hour is scarce. Microservices introduce immediate and non-trivial operational overhead: per-service CI/CD pipelines, service discovery, distributed observability (correlated traces, log aggregation, per-service metrics), API versioning management, eventual consistency between services, and circuit breaking. This overhead exists regardless of whether the system is in production or not. In small teams, this cost is paid entirely before any business feature is delivered.

Blast radius and failure isolation. Here microservices have a real advantage: a failure in the notification service does not bring down payment processing. In a monolith, a bug in low-criticality code can — if poorly isolated — affect the entire process. This argument is legitimate, but its strength depends directly on how well the monolith is structured internally. A modular monolith with clear separation of responsibilities, per-module error handling, and internal circuit breakers significantly reduces this risk without requiring distributed infrastructure.

Regulatory requirements. PCI-DSS and Bacen regulations require cardholder data segregation, access auditability, and eventually network isolation for components that process sensitive data. This creates real pressure for separation — but that separation can be addressed with module isolation + encryption at rest and in transit + granular access controls within a monolith, at least in the initial stage. Physical separation into distinct services can be deferred without violating regulatory requirements as long as compensating controls are in place.

The most common argument for microservices from the start is that "it is easier to start right than to refactor later". This argument has an implicit premise that is rarely examined: that you know what "right" is before having real customers.

In practice, the bounded contexts of a fintech emerge from real usage. What appears to be an "accounts" domain on day 1 frequently splits into "checking account", "payment account", "investment account", and "revolving credit limit" after six months of product feedback. If you have already built four separate microservices with their own databases, APIs, and pipelines, that refactoring carries enormous coordination cost: distributed data migrations, API versioning, coordinated maintenance windows across services, and risk of transactional inconsistency during the transition.

In a well-structured modular monolith, the same refactoring is a code movement operation within a single repository, with a single database to migrate and a single artifact to redeploy. The cost is a fraction.

This does not mean microservices are wrong — it means they are a solution to an organizational and technical scale problem that most greenfield fintechs do not yet have. Conway's Law is real: your architecture will reflect your team's communication structure. With 5 engineers, the optimal communication structure is a single cohesive team working on a single artifact with clear internal boundaries. Artificially distributing that team into "service teams" before having the scale for it is a way to create coordination overhead without the corresponding benefits.

Fowler's MonolithFirst pattern is not a recommendation to never use microservices. It is a recommendation to earn the right to use them: understand your domain well enough to cut the correct boundaries, and have the team and operational maturity to pay the cost of operating them.

The decision for a modular monolith only has value if it comes with explicit architectural discipline. Without it, the initial speed turns into structural debt in 12–18 months, and future extraction becomes as costly as premature distribution would have been.

Schema separation in the database. Each module accesses exclusively its own schema in PostgreSQL. Cross-schema queries are prohibited via code review and, ideally, via a separate database user per module (each module has a PostgreSQL role with GRANT only on its schema). This simulates the data isolation we would have with separate databases in microservices, without the cost of managing multiple RDS instances.

Formalized internal interfaces. Modules do not directly call classes or functions from other modules. Communication is done exclusively via public interfaces defined in the ports layer (Hexagonal Architecture). This ensures that, at extraction time, the interface already exists and can be converted to an HTTP call or event message without structural refactoring.

Automated architecture tests. Tools like ArchUnit (Java) or TypeScript equivalents (dependency-cruiser) are configured in the CI pipeline to fail the build if an unauthorized cross-module dependency is introduced. This is the only way to ensure that boundary discipline is maintained as the team grows and feature pressure increases.

Internal event bus as extraction preparation. Asynchronous communication between modules (e.g., Payments publishes PaymentCompleted, Notifications consumes and sends the receipt) is done via an in-process event bus. The interface of this bus is identical to what would be used with EventBridge or SNS/SQS. When the Notifications module is extracted, the only change is replacing the bus implementation with a real call to EventBridge — the producer and consumer code remains unchanged.

Documented and reviewed extraction criteria. The decision to extract a module should not be made under momentary pressure or because "we are already here". The criteria are defined now: bounded context stable for two quarters, team above 10 engineers, or specific technical requirement (differentiated scale, unacceptable blast radius, regulatory network isolation requirement). These criteria are reviewed quarterly at the architecture meeting.