Yes, to a point. But if you can easily paint yourself into a corner than the refactoring necessary to scale is so expensive it might as well be impossible.
Living that nightmare right now.
You don’t need to be “enterprise-ready” or “scalable”
181–185 of 185 posts
Re: You don’t need to be “enterprise-ready” or “scalable”
#182Earlier quoted context omitted.
Yep that’s the way to do it. One improvement IMHO would be to have an event log as the truth and everything else (in-memory/databases/…) derived from that event log. It is an architecture that scales from tiny to Google scale. You don’t even need something like Kafka. You can literally start with a single disk file as the event long and read it into memory at server startup. And then “scale up” by keeping the event l…
For business it is better to have "properly" designed database with the clean structure looking at which it is easy to understand how everything is organized and works. It can be used / interrogated by other software (writes are of course prohibited). Sure it will not do Google scale and I do not loose my sleep over it. For most "normal" businesses what I have is way more than enough. Besides, as I've already said I…
Not my experience at all. The problem with a “clean” “properly” designed database schema is handling migration and schema changes. Also, in an Enterprise environment, you end up having external systems relying on your schema, making it nearly impossible to upgrade the schema without breaking systems you don’t even know about until somebody shouts at you.
Re: You don’t need to be “enterprise-ready” or “scalable”
#183Earlier quoted context omitted.
I'd be interested to hear why you think this, or if you can link to something that explains this perspective.
There's a fundamental mismatch between the HTTP request-response model and the SQL "open transaction" model - you can't open a transaction, serve a form, and wait for a user to submit it and commit that in the same transaction, because what if the user walks away? But if a transaction doesn't extend to the actual user action then it's basically useless; you can't do transactional read-modify-write when the one doing…
What is the alternative? Use distributed databases that don't guarantee atomicity at all, and write up complicated solutions to work around it? Or are there some non-transactional, atomic databases that more nicely fit the web model that I don't know about?
Re: You don’t need to be “enterprise-ready” or “scalable”
#184Earlier quoted context omitted.
There's a fundamental mismatch between the HTTP request-response model and the SQL "open transaction" model - you can't open a transaction, serve a form, and wait for a user to submit it and commit that in the same transaction, because what if the user walks away? But if a transaction doesn't extend to the actual user action then it's basically useless; you can't do transactional read-modify-write when the one doing…
What is the alternative? Use distributed databases that don't guarantee atomicity at all, and write up complicated solutions to work around it? Or are there some non-transactional, atomic databases that more nicely fit the web model that I don't know about?
You have to write the "complicated solutions" anyway. SQL just lets you paper over the problem for longer. 99% of webapps lose data and don't notice or care, ACID is just a stick to beat other datastores with. IME something like Cassandra offers far more actually useful advantages (collection columns, true master-master HA out of the box) than an ACID/SQL database ever can.
Re: You don’t need to be “enterprise-ready” or “scalable”
#185You actually do need to have Enterprise security and authentication features if you intend to sell to Enterprise customers. (SOC2, OAuth, SAML etc)
Yep, I'm working at a Series B startup and I can tell you, you absolutely need SOC 2 or ISO and/or GDPR compliance based on your market. It's not optional, you will lose business if you don't.