Good for him. I am truly glad for him. But I don't really get the point of this type of articles e.g. `Brace yourself to become a billionaire`, `Watch out for hypregrowth`, etc.
I wonder why you would need to add engineers to scale an automated trading platform. Extra features, sure. But scaling? Shouldn't be an issue if things are reasonably designed.
Maybe for a SaaS product I could see some cleanup. But this doesn't sound like a responsible strategy in the fintech space. In any event, if you had 20 engineers already, surely they could simply fix their stuff or you could replace them with better staff who could. How much code does it take to implement a matching algorithm with some asset silos, an app, and a web interface or two? Not 20 engineers worth. This smells like VC tap-money gone riot.
At the height of the boom last year, Coinbase was signing up 50,000 new customers every day. Scaling would be a problem for any web app at that level of growth.
A large class of features are necessary for scaling: those that automate something that previously required a support call. Handling all the KYC verification for every state and country, for example, takes a lot of engineering.
Had to take a look at your profile and when I read "Formerly first employee and architect @ Kraken (2011-2015)" I spilled my coffee all over the place.
This Kraken which was barely usable during the hype?
Was the "Your transaction might have not succeed, please reload" message designed by you?
I was hoping for something like "don't use an AP NoSQL database for storing your financial transactions". I've always wondered how and why they chose MongoDB.
Coinbase was founded in 2012 in peak mongodb hype, and while the issues with MongoDB are well understood today, six years ago you'd have to be a cutting edge emerging database type developer to know that, and that's not the type of person who Y Combinator likes to fund.
NoSQL is a meaningless term, and SQL is a query language. The actual database types are relational, key-value/wide-column, document store, graph, search, OLAP/column-oriented, etc.
Any of them will work as long as you can durably store your data. Relational databases have always implemented ACID and SQL which makes them easy to work with, and they can support almost any data model with decades of updates and tooling which is why they are the default choice unless you specifically have other needs. Newer relational databases can also scale horizontally by applying the same sharding techniques as the other database types, so even that issue is no longer relevant.
If you subscribe to the Lean Startup learning where the author spent 2 years building out a product and then realized that nobody wanted to use it the heroku + mongoDB stack makes a lot of sense. It lets a startup to get a product out the door quick and figure out product market fit.
22 comments
[ 2.9 ms ] story [ 51.3 ms ] threadOK. I'll watch out. Thanks for the heads up. :D
Had see a company going through rapid growth I see some good tips there.
So ya they had a ton of tech debt to deal with to handle hyper growth.
This Kraken which was barely usable during the hype?
Was the "Your transaction might have not succeed, please reload" message designed by you?
Any of them will work as long as you can durably store your data. Relational databases have always implemented ACID and SQL which makes them easy to work with, and they can support almost any data model with decades of updates and tooling which is why they are the default choice unless you specifically have other needs. Newer relational databases can also scale horizontally by applying the same sharding techniques as the other database types, so even that issue is no longer relevant.