In this article, I will give you a no-brainer for choosing the right architecture for any project. Right doesn't mean perfect, but it does mean good enough.

You may or may not be a CTO, Lead Architect, or Principal SWE. You may be working on a greenfield or brownfield project. You may work in a startup or a megacorp. But at some point, you will be at the very beginning of a tech product, and you will need to choose a proper architecture for it. At least for MVP. At least before the first paying customers. At least before the first million users. At least...

There will be no deep analysis or theory. Just pure practice based on my own experience and knowledge. If your startup goes to the moon after reading this article, you can buy me a coffee.

Size Matters

One Man Army

Are you building an MVP, PoC, or read-only code to be thrown away after the first round of investment? Say no more - your soul architecture is Monolith. Yeah, it's not swag enough, nothing shiny to share at the smoothie unicorn meetup. There are bad rumors about Monolith, but fear not. It has proven to be very robust and powerful. Just think of SoC, invest in some readable code, use proper tools, and do not over-engineer - and you will be fine. Monolith will save you a lot of time, so much precious at this stage of your product - better spend this time improving your product or finally sleep.

Small Team

No longer MVP, but still small? Well, here we go again. Monolith is your best friend. Don't spend a lot of time communicating between parties, fine-tuning protocols, authentication, zero trust, routing, and service discovery - just put everything you want into a single application! It shouldn't stink, though. Build boundaries, separate logical blocks, and introduce abstractions. Build as if there are microservices, just don't break your application into cans of separate processes. Interfaces instead of RPCs, database transactions instead of SAGAs, imports instead of DNS. Run fast, but don't skimp on quality - there's a recipe for successful teamwork.

Part Of The Ship, Part Of The Crew

Do you have an ambitious team, do you work on an ambitious project, and it is expected to be huge? Does it belong to a single business domain? If so, Monolith probably fits here too. And why is that? Because it is very likely that you will share many of the same business entities and logic across applications. Breaking it up into many separate deployments will just make everything more complex and slower without providing any real benefit. That doesn't mean your service can't scale and handle peak loads. Design the application to be stateless, allow for concurrency, and stay cloud-native - and you will be able to scale it with ease. Read my blog for more tips on scalability, or ask me for a scalability workshop for your company (my own ad in my own blog, why not?).

Rich Man In Poor Man's Shoes

Have multiple domains, but still a small team? Not enough engineers to build a proper (5-7 members) team for each domain? I have news for you - Monolith is your friend. Why? Because without dividing engineers into separate teams, microservice architecture will not work. It only makes sense if each team is independent in terms of organization, only then they will be able to build properly isolated services without a distributed monolith. So why not build a centralized one? You still have all the tools to build a beautiful, well-architected, scalable, resilient service. But without a lot of the limitations that microservices impose.

Why not Lambdas? Well, the answer is maybe Lambdas. But you have to be sure that you know what you are doing. And so does your team. I will make a note about lambdas later.

Higher, Stronger

All The Colors Of The Rainbow

So you have many business domains, and your team is large enough to form independent domain groups? Congratulations, Microservices will work for you. Just don't forget the ground rules - no shared databases, no shared models, no state - only stateless, only APIs, only cloud-native. Microservices are very expensive, not just in cloud costs. They are much harder to build, harder to deploy and run, and harder to monitor and troubleshoot. With microservices, you have to bring a whole layer of supporting tools and roles - proper infrastructure (like Kubernetes), CI/CD, distributed observability, DevOps, DevSecOps, API gateways, and so on. I mean, a mature product will have all that anyway. It's just too expensive for a startup and completely slows down a small team.

Fear Is The Mind-Killer

Want to bring something new to the table? Something like lambdas? But you're afraid that when it's time to go, you'll be stuck with a vendor solution or sacrifice for a so-so vendor-agnostic solution. This fear is real, unfortunately, I could have told you to go for some open source vendor agnostic tools like Knative, but I didn't. Because I don't believe in them myself. While we are still waiting for a Kubernetes-level production-ready WASM orchestrator, Microservices architecture is still better for this case. Hopefully, this will change soon and the whole industry will move towards WASM-based architectures and tools.

The Spirit Is Willing, But The Flesh Is Weak

Still want lambdas, event-driven, reactive programming? Do you want functions, actors, monads? Well, brave one, ask yourself: does your team know all this shiny functional stuff? If the honest answer is no - bye-bye lambdas, hello Microservices. Seriously, choose either business goals or cool concepts, unless your team members are Clojure gurus. Otherwise...

Cherry On Cake

Yes, you deserve it. AWS Lambdas, Azure Functions, GCP Cloud Functions, Alibaba Functions Compute - you name it. You definitely know what you're doing, and your team worships the same god. Let go of the fear, and step into destiny. Let reactive architecture consume you. There is no turning back, and you know it. Enjoy.

Summing Up

For your convenience, I've organized all the ideas into a chart that you can carry with you at all times.