|
|
|
|
|
|
by mattmein
2613 days ago
|
|
|
I've never understood this advice. To me it just makes a lot more sense to store everything in the database - much less complexity. What I've done in the past is just put a CDN in front of the file url, so the file content is stored in the db, but served from the CDN. |
|
|
Even that article sort of acknowledges this, when it talks about being ultra conservative in your estimations of when this solution will start to fall apart.
Facebook can clearly not "just store all the photos and images in the db! It's less complex!" Same with Google.
To 4 or 5 or more nines of certainty, whatever you're working on doesn't now and never will have Facebook scale problems. And if it _does_, hopefully your business plan has you wallowing in cash-on-hand to pay teams of other smart engineers to help you solve that problem. (I'll respect you more if that pile of cash comes from customers buying your shit, but I'll acknowledge that wallowing in VC money you've raised on hockeystick growth or engagement numbers is also a valid path.)
If your business plan doesn't explain how you'll pay for a db.r4.16xlarge (or your cloud provider or on-prem db vendor's equivalent) with the number of users (or transactions/whatever-your-apporpriate-metric) that a topped-out vertically scaled db can support doing things the "easy and least complicated way", perhaps _that's_ a more important problem to be working on that ACID compliant deletion of user photos...