Lessons from Coinbase’s Wild Ascent | Hacker News Reader

Lessons from Coinbase’s Wild Ascent

firstround.com

71 pointstosh27 comments

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.

OK. I'll watch out. Thanks for the heads up. :D

First Round articles universally have this sheen of content free smarminess that reads like self parody, or something Mike Judge would come up with.

This article is more focused on how you should approach organization growth and re-structure.

Had see a company going through rapid growth I see some good tips there.

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.

I don't know; it sure seems like people understood the issues in 2010: https://news.ycombinator.com/item?id=1636198

I still don't understand them past "no PK/FK integrity" and duplicating data + problems with complicated queries.

What's the best current alternative database for storing financial transactions? Just use a SQL over a NoSQL?

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.

PostgreSQL all the way down. I know I'm in the minority here.

I doubt you're the minority TBH.

Probably OneTick.

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.

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.

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?

Dear snarky anonymous coward, if you read carefully you would realise that no, that all happened after I left (2015). Bonus reading: https://news.ycombinator.com/item?id=18140251 https://news.ycombinator.com/item?id=18140482

So your implying that kraken was a great system when you where there and only became a clusterfuck after you left? AFAIK they didn’t decide to exchange a perfectly working and scalable framework for one that was incapable of handling basic functionality for a larger user base during 2016, though I might be wrong. Feel free to enlighten me.

No idea what went on after I left. Just saw the media. I am sure if it had anything to do with me I would have been contacted.

To fix all the technical debt you (rightfully) incurred by focusing more on shipping than future-proofing.

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.

You'd be amazed. The first startup I worked at could barely maintain a CRUD web application with 15 experienced devs.

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.

My impression was most businesses in the space outsource this to specialist providers for legal reasons before and above internal process scaling reasons.

Fraud prevention, compliance, and security are the actual hard parts of running a cryptocurrency exchange. Doing these things well has largely determined the winners and losers in the space. I don't know of any major cryptocurrency exchange that outsources them.

So about a year before the crazy growth I interviewed there. Their platform at the time was on heroku and all the services were managed services.

So ya they had a ton of tech debt to deal with to handle hyper growth.

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.

Why? What is a signup? A couple of simple database writes (100k/day = non-issue for one server) and a bit of static content delivery (offload to CDN so zero impact), maybe an email (can use third party) or an SMS (again), accepting a file upload (mostly bandwidth issue, use cloud). It's not rocket science.

Reply on news.ycombinator.com