Hey everyone,
I'm currently in the early stages of planning the architecture for my app, and I'm at a crossroads between choosing a monolithic or microservices approach. I'm hoping to hear from anyone who has experience with either of these architectures!
To give you some context:
- The entire app will be built in Go, using 2 PostgreSQL databases plus a backup for the main data.
- If I go the microservices route, communication between services will be managed via gRPC with a REST gateway, all still in Go.
The app will initially feature:
- A **scheduling feature** (light on resources)
- An **analytics feature** (resource-intensive), primarily done in Go, but there's a small ML component handled in Python.
I plan to introduce more features over time based on user feedback and demand.
Here's what I envision for the ideal setup:
- Scalability as the user base grows
- Ability to update features without needing to redeploy everything
- A clean codebase that's easy for new developers to work with
- Cost-effectiveness (I'm considering hosting on GCP)
Since I don't expect many users at first—maybe just 5—I'm leaning towards a low-core VPS setup for the backend. It's a side project, so there's no rush to finish. If I decide on the gRPC microservice approach, I'd just run everything on the same VPS using Docker Compose.
So, my main questions are:
- What are the **pros and cons** of choosing monolithic vs. microservices for my application?
- Based on what I've shared, which approach do you think would be best and why?
Thanks a ton in advance for any insights or experiences you can share!
4 Answers
I’d recommend starting with a monolith. In my experience building companies, I realized that overthinking choices can lead to paralysis, especially when you're just starting out. Many side projects end up with more microservices than users, which is not ideal. It's easier to split a monolith later rather than trying to merge microservices back into one app. At your stage, just focus on building it. Optimization concerns like scaling and speed will come later when you actually have users.
Absolutely! Start small and only optimize when you start getting traction.
My take is to start with a monolith. You don't have users yet, so why stress about scaling? Focus on creating a product that people actually want before optimizing. Handling data migrations can be really tricky, and it’s usually a lot of work—not to mention it distracts from developing your product further.
Right? Prioritize getting a working product out there first!
Definitely! Get the basics down first before worrying about scaling.
I think a modular-monolith setup is wise. It allows you to structure your code logically while still deploying it as a single application. You can use different schemas for each module in your PostgreSQL instance without worrying about cross-schema references in the beginning. This way, you get logical separation and easier refactoring later on if needed.
Totally agree! Managing everything in one place initially makes life easier.
Yes! This helps make migrations smoother down the road too.
I’m in favor of starting with a monolith too, but design it modularly. This way, you can still break off parts into microservices later on as needed based on actual usage metrics. Over-engineering at the beginning can be a trap, so focus on core functionality first and think about splitting up only if and when it becomes necessary.
This is a great approach! Keeping things modular helps avoid unnecessary complexity.
For sure! Starting with a modular monolith gives you the best of both worlds.
Exactly! Focus on making a solid app first, then think about breaking things into microservices when the need arises.