Are you scaling horizontally?
When I first started working on Taskwise, I wrote much of the backend in C++ (partly because I knew it already) and didn't use a relational database because I thought it would be much easier to scale in the future. And I suppose that's all correct. But in retrospect, however, it seems rather overkill to go to such lengths when I'm still starting out. In realizing this, it made me curios; Do you scale your application horizontally (as in multiple servers) and if so, what technologies do you use (for ie. loading balancing, database, languages)?
Hopefully I reach a point where I need to think about scaling, but for now I'll be focusing on the basics. (P.S. I would be infinitely grateful for any feedback on my landing page!)
Trending on Indie Hackers
You can also use a model where you scale frontend app (multiple servers) and use one fast source of information (API connected to normal relational database).
For some use cases - like apps that rely on presentation of highly concurrent data (stock apps, bank apps with lots of transactional data) - using a sharded database (i.e. Mongo etc) is not really an option. In your case it will however work without a doubt (Mongo blocks when C*UD).
If you are familiar with relational databases, possibly with one in particular (like MySQL), I would just build it with that and think about scaling in the future. In my opinion it is better to solve these sweet problems when they arrive :)
P.S.: The landing page looks awesome and the app is snappy "af", great work. I also like the idea that you tracked the exact post from where I clicked it - perfect marketing effort. But my take on the product itself is that it is a problem that has been solved a million times before and is already integrated in a lot of enterprise platforms people already use. Try to come up with a feature set that sets you apart from those solutions and focus all communication into it (tagline, hero image on the page with screenshots etc.). I guess you already know that and I might just be too tired and missed it somehow. Thumbs up otherwise!
This is really helpful feedback! I totally agree that I need features that set my product apart from everyone else. In fact, I would say this is my biggest concern: going for an already saturated market. The one thing that I find so hard is coming up with ideas. But when I do come across something good, I'll definitely focus on validating the product and getting customers before scaling.
Thanks again and good luck!
Relational databases are really fast and if you have an issue where they can't keep up it's either very bespoke or means you're operating at a pretty impressive scale.
You can also have read hosts vs write hosts in a relationship database, where you have a single machine that all writes go to but a bunch of machines that can handle reads and the write host streams data out to them. In a lot of cases, there are a lot more reads than writes, so that works pretty well.
IME, the situations where database technology other than something like PostgreSQL is a great choice are pretty small but also a sign you're doing great so you can probably afford to do the refactoring. YMMV.
Great thing pointing out read/write hosts, I did a little bit of digging for my situation (MySQL) and found out MariaDB (clone of MySQL) has this a scaling solution already in place called MariaDB Galera Cluster.
One legacy commercial site I help built might need it soon, hopefully somebody will also find it useful.
I'm curious about what you implemented in place of a relational database!
They have decades of work behind them to optimize data storage and processing for common cases and I've worked with them at very large scale.
It comes down to architecture choices depending on your specific workloads and future needs.
Typically I find database need to be more centralized due to the fact that a write could affect all of the read queries. Application code can scale horizontally (with a load balancer and multiple servers) if it relies on the central database with no local storage. And various levels of caching and CDNs can offload non-unique requests for certain groups of users.
In my opinion the greater part of the work is always to get the customers or viewers to actually hit a large scale. I would always look to the easiest way to get things running for what you need now, with a view to upgrading the parts that need it once you get to a larger scale.
I 100% agree with that last part. I've now realized that what works right now is almost always the best choice, especially when getting started.
As for the database, I've used FoundationDB. It's an open source distributed key-value store maintained by Apple. It's kinda hard to manage and develop with, but I've built a Firebase-like API so that schema and business logic are fully contained in the client and require almost no server code. To be honest, building an API over top of FoundationDB was pretty fun and I'll use again for any future projects. Not to mention, it's super fast and lightweight.