Few architectural decisions generate more debate in software engineering than microservices vs. monolith. The microservices narrative dominated the industry from approximately 2014 to 2022, driven by high-profile Netflix and Amazon case studies. The pendulum has since swung: senior engineers at Amazon, Shopify, and Stack Overflow have publicly described returning from microservices to more modular monolithic architectures.

The engineering leader’s challenge is to cut through the case study marketing and understand what the research actually says about when each architecture is appropriate. This article does that and translates it into practical decision criteria for US tech companies building or evolving their products.

1. What the research says about microservices

The most cited academic analysis of microservices outcomes is Taibi et al. (2017, IEEE Software), which analysed 18 organisations that had migrated to microservices. Key findings:

– Teams that migrated primarily for scalability reported measurable operational complexity increases

– Teams with high developer experience and strong DevOps infrastructure reported productivity gains

– The primary adoption driver was “independent deployability” not scalability or technology diversity

A 2020 systematic literature review by Fritzsch et al. (Information and Software Technology, Elsevier) analysed 60+ papers on microservices adoption and found:

– Microservices increased operational complexity in all studies

– The complexity increase was net-positive for large teams (50+ engineers) and net-negative for small teams (<15 engineers)

– Organisational maturity DevOps capability, team topology alignment was more predictive of microservices success than technical factors

2. The modular monolith renaissance

The “modular monolith” pattern a monolithic deployment unit with internal modular architecture enforced by code boundaries has attracted serious attention from practitioners since 2020.

Shopify’s engineering blog (2023) documented their “componentisation” initiative: breaking a 10-million-line Rails monolith into modular components with enforced boundaries, while retaining monolithic deployment. The result: the developer experience and testability benefits of modularity without the operational complexity of microservices.

The academic backing for this approach comes from the Domain-Driven Design (DDD) literature, particularly Vernon (2013) “Implementing Domain-Driven Design” and Evans (2003) “Domain-Driven Design: Tackling Complexity in the Heart of Software” both Addison-Wesley which describe bounded context patterns applicable to both microservices and modular monoliths.

3. Decision framework: When each architecture fits

Choose microservices when:

– Team size exceeds 30-50 engineers with clear domain ownership boundaries

– Independent deployment velocity for different product domains is a genuine requirement

– Your organisation has mature DevOps capability (IaC, observability, service mesh)

– Scaling requirements are genuinely heterogeneous across services

Choose a modular monolith when:

– Team size is under 30 engineers

– Deployment frequency is uniform across the product

– DevOps maturity is still being established

– The product domain boundaries are still evolving (premature service separation causes expensive restructuring)

Choose to refactor (not rewrite) either when:

– You have a working system with real users

– The bounded context boundaries are understood from usage data

– The Strangler Fig pattern (Fowler, 2004) can be applied incrementally

4. How nearshore teams support architecture evolution

Architecture decisions are not one-time choices. They require ongoing stewardship engineers who understand the original rationale for each decision and can evaluate when it should be revisited.

This is precisely the work that rewards low attrition. Cafeto’s 7% attrition rate means the architects who designed your service boundaries are still on the team when those boundaries need to be renegotiated.

Conclusion

Microservices are not universally better than monoliths. The research is clear on this. The right architecture depends on team size, DevOps maturity, and domain stability. The engineering leader’s job is to apply this framework honestly without cargo-culting the Netflix architecture for a product that Netflix’s case study doesn’t apply to. Cafeto’s senior engineers can help you make this decision with evidence, not fashion.

Bibliography

• Evans, E. (2003). Domain-driven design: Tackling complexity in the heart of software. Addison-Wesley Professional.

• Fowler, M. (2004). Strangler Fig application. Martin Fowler’s Bliki. https://martinfowler.com/bliki/StranglerFigApplication.html

• Fritzsch, J., Bogner, J., Zimmermann, A., & Wagner, S. (2019). From monolith to microservices: A classification of refactoring approaches. Information and Software Technology (Elsevier). https://doi.org/10.1016/j.infsof.2019.01.014

• Taibi, D., Lenarduzzi, V., & Pahl, C. (2017). Processes, motivations, and issues for migrating to microservices architectures: An empirical investigation. IEEE Cloud Computing, 4(5), 22–32. https://doi.org/10.1109/MCC.2017.4250931

Book a Consultation to learn about engineering operations to Colombia:

https://outlook.office.com/book/[email protected]/?ismsaljsauthenabled

Learn about: The Changing Economics of the H-1B Visa here