Allen Hartwig 🥜 on LinkedIn: Nut Tree w...
@allen thanks so much for the kind words! right now in Convex's stage, nothing matters more than you all talking about Convex if you feel it's authentically a good platform and team. so we can't overstate how much sharing enthusiasm with the rest of the web matters for us. ( https://www.linkedin.com/posts/allenhartwig_nut-tree-went-from-idea-to-market-in-under-activity-7154155376106459136-36e_?utm_source=share&utm_medium=member_desktop )
Allen Hartwig 🥜 on LinkedIn: Nut Tree went from idea to market in u...
Nut Tree went from idea to market in under 60 days, with a heavy emphasis on delivering something users would LOVE.
To accomplish this, the right tech stack… | 15 comments on LinkedIn
8 Replies
No problem!
A follow up post as some questions about scaling and tech debt came up in the thread.
https://www.linkedin.com/feed/update/urn:li:activity:7155600740026085376/
Allen Hartwig 🥜 on LinkedIn: I recently shared the tech stack used ...
I recently shared the tech stack used to launch Nut Tree and had some great follow up questions on scalability and tech debt.
Let's tackle those here…
My…
Hopefully I'm not over extending you with that call out, @Jamie 😅
no problem at all
we'll probably write a blog post at one point, but one thing I learned that I was completely oblivious about before Dropbox: scaling is a process, not really a characteristic. systems aren't scalable, teams and culture know how to scale. Every system is only provably scalable just beyond the largest load it's driven to satisfaction. "Scaling" is the process of improving that system fast enough (while holding necessary quality) to keep up with the next largest load. So systems aren't scalable, but teams can be built to scale with the right expertise and culture (and hard freakin' work, tbh)
IME the only system that's not scalable is one that's been designed without keeping in mind what happens 2 or 3 or 4 generations after this one. making promises you can't keep or whatever. but otherwise, that gen 1 system may not be able to take much load today (no gen 1 system is, it takes many dev-years of work), but it's about: "is it shaped appropriately to improve with a team that knows how?"
For sure. The questioning didn’t seem in good faith. Or it’s coming from a pure eng perspective without larger business considerations. Either way, felt it was a good opportunity to plug you and your team.
Was having flash backs of mongodb “webscale” memes.
yeah, appreciate it. and I think devs challenging the practicality of using a new platform like ours that would play such a critical role for your team + project is always fair play and a hard question we always need to be ready to answer. but big ❤️ for the show of faith!
To me, the faith is less about scaling concerns. If you can’t deliver there, it’s a good problem to have, and will cross that bridge when I get there. The more immediate trust is in the proprietary database. Something goes sideways there and all my customer and app data is lost, I’m pretty much done for without starting at ground zero. I know you have tools to deal with this, but still overhead on my part to manage. No real ask with this, just giving insight to where I feel exposed as a convex customer.
Going with a managed db option like rds or cloud sql makes backup/restore more seamless giving sufficient coverage for early stage without additional config or management.
yeah, that's fair
so, a little behind the scenes on this for a minute
we've (convex team) built a replicated system before--responsible for no data loss etc. failover/redundancy semantics, bleh bleh ablah blah
it was a pretty darn good one
it was a SHIT ton of work
it took forever
so convex early days we are not doing that. no way no how. it's too much work to get right and we know that has to be air tight with you all. durability > (availability/performance) with this kind of product
so convex is on RDS too right now
your records are on RDS, using RDS's snapshots/replication/failover etc
this is relatively expensive for us, but we'll have time to optimize that later with a bigger team and more time
for now we want to just have an unexciting time when it comes to the integrity/durability of your data. we don't have time to get it right to the same standards as AWS
so hopefully that's a bit of reassurance on our attitude being aligned there, and a little more info on what's under the covers right now. happy to answer any more questions
That insight is helpful and reassuring. Perhaps expose that in your docs and what retention / recovery policies are. At the moment I just see snapshot cli, my eyes glaze over, and I go back to crossing my fingers and building my product.