If I were to guess, they've probably invested heavily in building a bunch of "high availability distributed systems" when they should have just stuck to MySQL or Postgres.
I don't disagree with the thesis of your comment but I feel like people often use this reasoning to simply avoid doing any kind of architecting.
Yes, something with Postgres and PHP is probably ok for a lot of usecases, but a) Robin Hood is a pretty big target, and might exceed the simple limits of that, and b) there are plenty of cases where Kubernetes (or any other big orchestration framework like Mesos or Nomad or Docker Swarm) will simplify the codebase.
I'll agree that engineers are sometimes a bit too eager to just jump on the new HN tech a bit too early, but it's not like that tech isn't useful, and it's not like it doesn't serve some kind of purpose.
I agree on the need for architecting, except that there's a tendency to do that waaaay prematurely.
You don't know where the best place to fragment your monolith is until you've got to the point where there monolith is struggling to keep up, because then you know where the slow bits are and how to scale them.
And there's no need to split the whole thing. You can just split off the slow bits.
Starting with Kubernetes from the get-go seems insane to me.
I don't run a big successful website, but I do run a Kubernetes cluster at home in my basement. Why? Because the computers I run everything on are six Nvidia Jetson Nanos; I'm a fan of running these because I like having access to a good GPU, and I can leave them running 24/7 without having to feel too guilty about power usage.
Just one Nvidia Jetson Nano wouldn't be enough to handle all my server needs (movie streaming, video transcoding, random odds and ends of projects I have), and using a framework like Docker Swarm or Kubernetes makes this relatively easy.
Is having the ability to linearly scale my home server overkill? Maybe, but at the same time it certainly felt necessary for the job, and carries the nice advantage that I don't have to rearchitect everything later while trying to shoehorn in the "old" way of doing stuff for compatibility sake.
> You don't know where the best place to fragment your monolith is until you've got to the point where there monolith is struggling to keep up, because then you know where the slow bits are and how to scale them.
Sure, it's not a silver bullet, and I certainly wouldn't claim it as such. That said, there are reasonable places to expect bottlenecks that can benefit from an architecture; things hitting a spinning disk or making an external HTTP call tend to be slow, so it is often better to model them asynchronously and buffer through a message queue; even if you don't have concrete numbers on your side it's not an unreasonable assumption to make.
Dont get me wrong I'm not a fan of over engineering things.
But those two statements are not mutually exclusive. You can build scalable distributed systems with postgres as a backend, heck if I was building one that would be a core part of my stack...
That is pure speculation. And people that use MySQL have outages also especially at this level of load. At my company we are just using PHP and MSSQL and we have our DB go out even on our internal apps on nearly a daily basis due to load problems.
I can't imagine our DBs holding up to millions of users or need to process millions of ticker symbols or trades.
Its extremely difficult to cut over millions of lines of code and 15+ years of development. We are working on it, but the db was never properly sharded and that is very difficult to do at a late stage. When you work on big enough projects the common sense approaches break down. FB messager doesn't use MySQL, Amazon shopping cart doesn't use Postgres. There is a reasons why. This isn't a wordpress app, it needs to process 10s of thousands of updates a second and still be a responsive app with 99.9% uptime and low SLAs on requests.
I think everyone did similar templating for similar applications. For example Golang apps which have logging/metrics already built-in instead of needing sidecars.
> One notable project is to provide an intuitive, user-friendly frontend for executing GitOps workflows on Applications and Component manifests.
Is this supposed to automatically update manifests, deploy them to staging namespace/automatic tests, enable automatic canary deployments?
> We also hope to go even further and create a one-touch infrastructure-provisioning interface to abstract away manifests altogether, and place application-centric abstractions even more front-and-center for application developers.
How does that look like? Archetype-Specific web interfaces/manifests?
I'm kinda sad that this isn't available to the general public since I'd love to avoid constant repetition/writing my _limited_ own version.
It's funny you mention this, because I've heard from people who've interviewed with Robinhood that they're still on a single monolothic RDS instance for a good portion of their main application. If I had to guess, a single RDS instance would be a more likely cause, something like a table growing too large (an audit log table perhaps).
TD Ameritrade is pretty good, as is tastyworks. Interactive Brokers is great for price and execution, but their tooling is not wonderful. For options specifically, I would go with tastyworks.
I don't want to pay $75 to move my shares to another broker. I also don't want to risk selling all my shares right now, transferring the money to my bank, then transferring it to another broker, and buying them again and risking the market coming back during that process and losing thousands of dollars. There's probably a way to transfer out faster for free, but I don't know it. Any new money I invest will be in a different broker, though.
This plus I don’t trade enough that the downtimes matter. I buy twice a month on a fixed schedule they’ve not been down on any of those times so I wouldn’t know they have issues if it weren’t for the news.
The question there is did you lost more than $75 not executing trades you wanted to execute? There's risk but a lot of risk in a platform that might crumble because its a startup.
I moved from Robinhood to Schwab, and didn't know about this fee on Robinhood's side. So I ask Schwab support and they not only told me about it, they gave me an additional $75.
YMMV but I think most brokerages would be happy to help if you ask.
All of my positions are long, and temporary outages like these have no impact on my trading performance.
If I were just starting out I probably wouldn't select Robinhood given the recent issues, but I don't see the need to change to a different platform at this time.
There's no reason to be on RH anymore if you're buying/selling shares. But they do offer free option trades, whereas you need to pay $0.65 per contract on Schwab for example. Personally, for the volume of options I trade, I just use Schwab and feel I'm paying $0.65 for a much better trading platform and research data availability (Schwab Trade Source).
I had a director who used to say "You know that would be a good problem to have." whenever scaling discussions come up (i.e "How would we handle 10M users?").
And as an engineer, I used to point how Twitter's fail-whale was killing Twitter just before it got popular.
After almost a decade, now I get what he meant. And I'm more interested in jumping into a company with technical problems like these, with short time horizons rather than those with capital restrictions or chasing PMF in early stages.
Ruby may be slower than other languages, but generally speaking your scalability issues will never be solved by rewriting in another language.
A rewrite may give you a temporary relief if the runtime of your new language is say 10% faster than your current one. This is not a long term solution though, and for many startups in hyper growth state, this will just give you a few more weeks of runway until you run into the next roadblock.
Your solution to scalability issues should almost always be system redesign, not component rewrite.
The Fail Whale is always my go-to when explaining why we should ignore scaling until we need to. If people need the solution and love the product, they'll be patient while tech problems are fixed. It's better to create a lovable product than a scalable product.
I assumed the outages were caused by features lacking in the product, rather than the tech stack (e.g. not accounting for leap days if that were true).
I also assumed that the recent outage was due to not accounting for yesterday’s circuit breaker. I imagined there’s a Robinhood product manager with a JIRA ticket who’s complaining about their feature getting depriortized every month.
52 comments
[ 3.2 ms ] story [ 110 ms ] threadYou're right, they probably are having issues with some lasagna architecture right now.
Yes, something with Postgres and PHP is probably ok for a lot of usecases, but a) Robin Hood is a pretty big target, and might exceed the simple limits of that, and b) there are plenty of cases where Kubernetes (or any other big orchestration framework like Mesos or Nomad or Docker Swarm) will simplify the codebase.
I'll agree that engineers are sometimes a bit too eager to just jump on the new HN tech a bit too early, but it's not like that tech isn't useful, and it's not like it doesn't serve some kind of purpose.
You don't know where the best place to fragment your monolith is until you've got to the point where there monolith is struggling to keep up, because then you know where the slow bits are and how to scale them.
And there's no need to split the whole thing. You can just split off the slow bits.
Starting with Kubernetes from the get-go seems insane to me.
Just one Nvidia Jetson Nano wouldn't be enough to handle all my server needs (movie streaming, video transcoding, random odds and ends of projects I have), and using a framework like Docker Swarm or Kubernetes makes this relatively easy.
Is having the ability to linearly scale my home server overkill? Maybe, but at the same time it certainly felt necessary for the job, and carries the nice advantage that I don't have to rearchitect everything later while trying to shoehorn in the "old" way of doing stuff for compatibility sake.
> You don't know where the best place to fragment your monolith is until you've got to the point where there monolith is struggling to keep up, because then you know where the slow bits are and how to scale them.
Sure, it's not a silver bullet, and I certainly wouldn't claim it as such. That said, there are reasonable places to expect bottlenecks that can benefit from an architecture; things hitting a spinning disk or making an external HTTP call tend to be slow, so it is often better to model them asynchronously and buffer through a message queue; even if you don't have concrete numbers on your side it's not an unreasonable assumption to make.
https://robinhood.engineering/building-an-application-deploy...
Eventually you will reach a point where you will need clever and fast code.
Dont get me wrong I'm not a fan of over engineering things.
But those two statements are not mutually exclusive. You can build scalable distributed systems with postgres as a backend, heck if I was building one that would be a core part of my stack...
I can't imagine our DBs holding up to millions of users or need to process millions of ticker symbols or trades.
What?? How could your team live with that?
https://robinhood.engineering/building-an-application-deploy...
I think everyone did similar templating for similar applications. For example Golang apps which have logging/metrics already built-in instead of needing sidecars.
> One notable project is to provide an intuitive, user-friendly frontend for executing GitOps workflows on Applications and Component manifests.
Is this supposed to automatically update manifests, deploy them to staging namespace/automatic tests, enable automatic canary deployments?
> We also hope to go even further and create a one-touch infrastructure-provisioning interface to abstract away manifests altogether, and place application-centric abstractions even more front-and-center for application developers.
How does that look like? Archetype-Specific web interfaces/manifests?
I'm kinda sad that this isn't available to the general public since I'd love to avoid constant repetition/writing my _limited_ own version.
YMMV but I think most brokerages would be happy to help if you ask.
If I were just starting out I probably wouldn't select Robinhood given the recent issues, but I don't see the need to change to a different platform at this time.
And as an engineer, I used to point how Twitter's fail-whale was killing Twitter just before it got popular.
After almost a decade, now I get what he meant. And I'm more interested in jumping into a company with technical problems like these, with short time horizons rather than those with capital restrictions or chasing PMF in early stages.
I remember they were one of the first to really adopt Scala. They still use it quite successfully.
A rewrite may give you a temporary relief if the runtime of your new language is say 10% faster than your current one. This is not a long term solution though, and for many startups in hyper growth state, this will just give you a few more weeks of runway until you run into the next roadblock.
Your solution to scalability issues should almost always be system redesign, not component rewrite.
I also assumed that the recent outage was due to not accounting for yesterday’s circuit breaker. I imagined there’s a Robinhood product manager with a JIRA ticket who’s complaining about their feature getting depriortized every month.