On the tech side, they continue to build on top of a broken foundation (MongoDB), resulting in millions of man hours wasted dealing with the complete lack of transactions. Mongo now has transactions, but last I heard Stripe was still running a very outdated version and spending absurd amounts of time dealing with issues that transactions would have entirely avoided. If you suggested that maybe it'd be worth changing course to something like Postgres because of the insane amount of work being wasted, you'd be shut down for not being optimistic enough.
Having worked at Stripe, these exact examples came up more than once. I can verify their authenticity.
Handling money is serious business and if one insists on using the unproven flavor-of-the-week to do so, they'd better make sure it has at least the fundamental requirements to accomplish its task, e.g., transactions/MVCC. Stripe apparently failed to do so, and has chosen to propagate that failure for many years.
One can make excuses for the spunky startup with a handful of employees needing to save time by using what they know or whatever, but Stripe is well past that point, and serious people should've taken over by now. I'd expect "replace Mongo with a real database" to be near the top of the todo list for any serious people.
The same cannot he said for a number of other services we use, including those from some companies with supposedly very good tech credentials. We’ve had to back out of integrations due to the clear evidence that they are non transactional and/or eventually consistent.
What storage options don't have the ability to delete all your records at once quickly? If it was MongoDB there would surely be an index attaching the data to your account. Same with PostgreSQL.
You seem to indicate that Stripe has consistency issues with their payment APIs. Have you seen this? Having worked directly on these APIs (note, I said ON and not WITH, I worked at Stripe on these products), it would greatly surprise me to see non-trivial consistency issues with their data model that surrounds money movement. Stripe might be on Mongo, but assuming that they have consistency issues because of that is quite a leap. Remember, Stripe is regulated federally and in most states, as well as in their international jurisdictions, so the claim you are making would be one regulators might be interested in if there is any veracity.
You also seem to be insisting that there are no "serious people" at Stripe, and that might be true! At least, I hope no one has mistaken me for a "serious person". But what does "serious" mean here and why can only "serious people" work on financial infrastructure? Moreover, why do "serious people" not see Mongo as a "real database"? In fact, what is a "real database" to you, other than something that has transactions?
I'm very interested in your answer here; while I had my issues with Mongo in my 2.5 years at Stripe, most of the issues I encountered I would lump into the "this is a trade-off consequence" bucket, as Mongo solved a whole lot of other issues for me. The other main bucket I would have used was "distributed database problem". I know Stripe had no plans, nor should they, to move to a non-distributed data store.
No one is forcing you to use Stripe, but I would suggest that attacking Stripe for their technology usage is not very useful.
How about "Atomicity, Consistency, Isolation, Durability"? That would be a good start for a database.
A nearby comment suggests lack of set-based operations (e.g. delete), so that would be another nice thing to add.
Just wait until you find out what technology actual banks use!
How do you say this without knowing that governments around the world feel the same way and so heavily regulate this space? Do you know any publicly available recommendation from these regulators against MongoDB?
> replace Mongo with a real database to be near the top of the todo list
This is where the businesses separate themselves from technology enthusiasts. Let's assume this is made the top priority, in your opinion, what task immediately follows? Or what former priority does it replace?
If there isn't one, there should be.
>Let's assume this is made the top priority, in your opinion, what task immediately follows? Or what former priority does it replace?
Mongo jeopardizes the overall security and reliability of the system, thus exposing Stripe to serious liability, so I'd say replacing it is part of the basic expectation from any production-level computer system. Obviously I don't have a copy of "Important Stripe Person's Priority List", but I'd assume such basic functionality is part of an implicitly-assumed functional baseline, and that Stripe would expect said important people to escalate and develop a plan to handle such a fundamental flaw ASAP.
If we were just tracking people's favorite cat videos or something, it'd be one thing. Attacks targeting malicious data modification and exploitation of races wouldn't really be that much of a concern. It's not great to have that attack surface but not necessarily the end of the world if someone's favorite cat videos get added to their account 1000 times. But when we're dealing with money, this kind of thing needs to be taken seriously, and tacking on a big pile of crap in front of the datastore is not a serious way to address its fundamental shortcomings, at least not when there are many better, proven options on the market.
Just in case someone thinks I'm being an alarmist here, this has already happened; multiple bitcoin exchanges have been pwned due to their reliance on Mongo's flawed semantics. [1] I can only assume that systems like Stripe haven't been attacked similarly because it would provoke the ire of much bigger fish, and why do that when you can knock over smaller bitcoin exchanges?
[1] http://hackingdistributed.com/2014/04/06/another-one-bites-t...
But the optimism point resonated. Before reading your comment, I actually reflected on whether I am being pessimistic. I'll tell you why: at this point in the game, cleaning up the software would effectively require a rewrite. And the company is in no position to do this. They do not have the talent, leadership, or effective recruiting necessary to undertake a meaningful second system effort.
So I think I've come to the realization that the job is a poor fit and I should move on, but while I am here it actually wouldn't help pointing out the obvious issues with the system. There really is no point.
You simply chew through those complications. Again and again. And try to optimize your application for less complications in the future, if possible.
In smaller startups, where you might be able to steer more aggressively, you should still ask yourself whether the company is clearly in the wrong direction only from your perspective or if there are factors which you don't have any insight into (no matter how close you are to founder(s)) which would re-contextualize the issue.
Not disagreeing, but these are some caveats which I found useful to keep in mind.
[1] - There was a story about someone from Apple(?) here a while ago who was let go after a lunch with <someone important> where he expressed his dissatisfaction with the company's direction. He then took up japanese caligraphy. Maybe someone remembers and can link it here.
Optimism can possibly mean anything from not blocking new initiatives through year-long corporate approval processes to cult-like you-have-to-drink-our-kool-aid internal communication that shuts down any and all critical voices and oversells what a company is doing and where it is currently at even to their own employees internally.
For me personally, optimism is a good thing when it means not taking issues as set in stone, genuinely believing that the future will be better than now and that one has some amount of control over that, and trying things out that might not work instantly - all while retaining one's critical thinking and being honest about the facts.
I have never met anyone who works at stripe or heard an inside take, but from the interviews with the founders I've heard, they don't strike me as the kind of people to push the delusional kind of "optimism" and shut down critical voices.
However, what they are really talking about is that "why will it fail" is a "conversation ender", and "how might it work" is a "conversation continuer".
Those are probably bad terms, but hopefully you get my drift. One promotes conversations to end, and one encourages conversations to continue. I would personally promote that viewpoint instead to keep people from doing exactly what you are talking about.
There's a clear difference between giving an unusual or unconventional idea a chance; versus allowing an idea guy to let his imagination run away.
In the former, giving an unusual or unconventional idea a chance, is how progress is made. Fundamentally, a startup is always taking a chance on an unusual or unconventional idea. (When I worked for a successful startup, a lot of people at networking events thought what we were doing was weird and unconventional. It wasn't.)
In the latter case, when an idea guy is allowed to let his imagination run away, it just kills the company. Either he's wasting all his time, or even worse, wasting everyone else's time. (These are the kind of people who's whine that "we're supposed to be optimistic" when everyone in the room clearly rejects their ideas.)
I finally came to the conclusion ( for now ) that these sort of super optimism persist precisely and only because they are Startups.
Optimism as a Culture only works when it happens from those who held power to all the way down. It doesn't really work bottom up. When the company Culture is toxic, or bureaucratic as in every large companies, no optimism is going to save you.
In Startup, everyone is in it together, and it is mostly a flat or very thin structure. There is a huge transparency in vision and Goal. Everyone knew what their others are doing, and as long as everyone is fighting for it there will always be a fighting chance.