Hey everyone! I'm at the beginning stages of building my app and I'm really stuck on whether to go with a monolithic architecture or switch to microservices. I would love to hear from anyone who has experience with either option. Here's a bit of context:
My app will be developed in Go, utilizing two PostgreSQL databases plus a backup for the main data. If I opt for microservices, I plan to use gRPC for inter-process communication with a REST gateway, all in Go.
Right now, my app has two key features:
- A low-intensity scheduling feature
- A CPU-intensive analytics feature (mostly in Go, with a bit of ML in Python)
I intend to add more features as I get feedback from users.
What I'm aiming for:
- Easy scalability as user demand grows
- The ability to update features without full redeploys
- A clean codebase that's easy for other developers to contribute to
- Cost-effective hosting on GCP
Initially, I anticipate just 5 users, so I'm thinking of starting small with a low-core VPS for my backend, using Docker Compose for a microservices approach if I go that route.
Can anyone share the pros and cons of both approaches in this context and what would you recommend? Thanks in advance for your thoughts!
5 Answers
Go for the monolith. You don’t have customers yet, so don’t waste your time and resources on scaling issues. Focus on solving the core problem and building out your features. Once you’ve got user feedback and a grasp on what's actually needed, then think about whether a microservice architecture is necessary.
Honestly, starting with a monolith but keeping the design modular is the way to go. If you structure it well, you can always split out parts into microservices later when necessary. Don’t over-engineer things at this stage—just keep it simple and focus on delivering a great product. And remember, there's no need to build everything yourself; use existing solutions for non-core functionalities like authentication.
I vote for a modular monolith too. It lets you keep everything bundled into a single application while you develop. You can set it up to allow for individual modules that you could then split off if they really need separate scaling. Besides, managing a single service is way less of a headache in the beginning. Just keep everything tidy and clear, and you’ll have an easier time if you decide to scale later.
I'd recommend you start with a monolith. I've built a couple of companies and early on, I just pieced things together without overthinking it. Many side projects end up with more microservices than users, which is just overkill. It's easier to break apart a monolith later than to try merging microservices back into one. Focus on building something solid first instead of stressing about scaling or response times—those are concerns for later once you have real users.
I lean towards microservices just for their long-term flexibility, especially with how GCP supports cloud run. But, I'd still suggest starting simple and evaluating how the app grows. Handling microservices can be tricky, so make sure you really need that setup before going all in.
Related Questions
How To: Running Codex CLI on Windows with Azure OpenAI
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically