by dondraper36 on 12/24/23, 9:10 PM with 9 comments
https://www.listennotes.com/blog/the-boring-technology-behind-a-one-person-23/
https://anthonynsimon.com/blog/one-man-saas-architecture/
There are a lot of resources on distributed systems and interview preparation where the focus is on FAANG scale, distributed setups, exobytes of data, which is cool if you are working on such a project but most likely you are not. I am not, for example.
I really admire these articles because their authors have such a great understanding of many different aspects of development.
While reading them, I noted to myself that I personally can't even answer with confidence what a single reasonably fat server can handle with just a web server and Postgres.
I have also always worked with managed DBs because it so happened that the companies I worked for are active cloud users.
Even worse, even at mid sized companies, a lot of complexities like load balancing and DNS are handled by dedicated teams and you just have to read the documentation and hope that K8s managed by the admin team does everything for you.
It really makes me feel incompetent to realize that what the authors of these posts implemented on their own, is not something I could do.
On the bright side, I really think I'd like to fill the gaps.
Maybe, there are some resources that build things up incrementally with a focus on simplicity but at the same time do not take anything for granted?
I have read Designing Data Intensive Applications, it's my favorite book but, honestly speaking, even the title says that it's about large scale.
by romanhn on 12/24/23, 11:28 PM
The good news is you should stop worrying about this stuff, and just build. You'll eventually run into bottlenecks and can address them then. That's how best learning happens anyways. Premature optimization is fun and intellectually stimulating, but rarely gets you closer to delivering value.
My rules of thumb for starting out:
- Start with a monolith (microservices are great for certain problems, but it's very unlikely you'll have those problems in the beginning, and they add quite a bit of complexity)
- Use a relational DB (same caveats as above for NoSQL, RDBMS can handle search well enough early on as well)
- Use managed services as much as possible (cloud > managing your own hardware, RDS > managing your Postgres instance, etc). They typically have sensible defaults, provide greater security/scalability/availability, and let you focus on the product.
- The fewer independent moving parts in your architecture and infrastructure, the better. Let the complexity add over time, as needed.
by tacone on 12/26/23, 1:19 PM
by solardev on 12/24/23, 10:46 PM
You can replace each part of it as you need to (like using postgres instead of MySQL or Ruby or Python instead of PHP).
This definitely can't hyperscale, but it's how small and medium websites all used to be made. Good way to learn by doing if that works for you.
by mikewarot on 12/25/23, 3:06 AM
It's long, but extremely useful. It is full of wisdom.
by revskill on 12/25/23, 3:47 PM
Give me your interpretation of what does "microservice" mean, then i could give you more clear context.
by kunqiana on 12/26/23, 5:39 AM