We have a similar check in our Haskell codebase, after running into two issues:
1. Nested database transactions could exhaust the transaction pool and deadlock
2. Same as you described with doing eg HTTP during transactions
We now have a compile time guarantee that no IO can be done outside of whitelisted things, like logging or getting the current time. It’s worked great! Definitely a good amount of work though.
This might stem from the domain I work in (banking), but I have the opposite take. Soft delete pros to me:
* It's obvious from the schema: If there's a `deleted_at` column, I know how to query the table correctly (vs thinking rows aren't DELETEd, or knowing where to look in another table)
* One way to do things: Analytics queries, admin pages, it all can look at the same set of data, vs having separate handling for historical data.
* DELETEs are likely fairly rare by volume for many use cases
* I haven't found soft-deleted rows to be a big performance issue. Intuitively this should be true, since queries should be O log(N)
* Undoing is really easy, because all the relationships stay in place, vs data already being moved elsewhere (In practice, I haven't found much need for this kind of undo).
In most cases, I've really enjoyed going even further and making rows fully immutable, using a new row to handle updates. This makes it really easy to reference historical data.
If I was doing the logging approach described in the article, I'd use database triggers that keep a copy of every INSERT/UPDATE/DELETEd row in a duplicate table. This way it all stays in the same database—easy to query and replicate elsewhere.
You shouldn’t get the device verification requirement if you’ve used the device before (we store a permanent cookie to check this) or for the same IP. Any chance your cookies are being cleared regularly?
We added this after attackers created clones of http://mercury.com and took out Google ads for it. When customers entered their password and TOTP on the phishing site, the phisher would use their credentials to login and create virtual cards and buy crypto/gold/etc. The phisher would also redirect the user to the real Mercury and hope they figured it was a blip.
This device verification link we send authorizes the IP/device you open it on, which has almost entirely defeated the phishers.
Since WebAuthn is immune to this style of phishing attack, we don’t require device verification if you use it. I highly recommend using TouchID/FaceID or your device’s flavor of WebAuthn if you can—it’s more convenient and more secure. You can add it here: https://app.mercury.com/settings/security
That said, we are talking internally about your post and we do recognize that as IPv6 gets more traction IPs will rotate much more regularly, so we’ll think if we should loosen restrictions on being a same-IP match.
I think database schema docs are really valuable, so much so that I added tests that require docs for each table and column. But I still got asks that the docs needed more information, mostly from data science people (who otherwise need to go bug engineers, or end up writing bugs in their own SQL). So I wrote internal guidelines for documenting database tables, and eventually that became this blog post
100% open rate on transactional emails feels too high to me. Something like an e-commerce purchase might kick off multiple emails (purchase made, shipped, arrived), none of which the user opens
It’s pretty common to use ad network mediators, which try multiple ad networks for an ad, to optimize for using high earning ones first, and falling back to others in case the first network didn’t have an ad to show.
Just as one data point, Mercury has hired maybe ~120 Haskell engineers in the last 4 years. Some of that is reflected in these job posts but we definitely hired a lot more than we posted on the subreddit.
It’s also a huge vector for actual phishing, especially because google ads doesn’t use puny code, so it’s easy to buy ads for sites that differ by just a diacritic
You as the customer are the owner of record on the funds. The accounts are held by our partner banks at these other banks, as your agent and custodian (something like "Evolve Bank and Trust for benefit of Acme Corp).
The FDIC insurance applies to the business holding the funds; it is definitely not insuring Mercury itself.
You do need to use Mercury to withdraw the funds; we still run all the authorization and compliance rules around this, and there isn't a facility for you to go into eg United Texas Bank and ask for your money. That said, if Mercury were to go bankrupt tomorrow, your funds are held by our partner banks who have full KYC/KYB info on you would be able to access all your funds.