the whole article read to me like a guide: How to over engineer a project for kicks and giggles.

It clearly explained what the design constraints were and why the technology choices met them

how would you under engineer your bank?

You don't have to choose between under and over engineering

Perfectly engineering is nearly impossible. In my experience systems always end up under or over engineered. The distinction also depends on what's on the backlog – if you have a feature that's going to be hard to implement because of inflexibility, you're under-engineered, if it's easy but other features require more work than they should, you're over-engineered.

I can't make a judgement call on whether they're over or under engineered, but it's good to pick which one you would rather be, write that into your engineering team's DNA, and then learn to work with it.

exactly this. I see it as this: over or under engineering can basically be boiled down to requirements and budget (which is itself a requirement, but many engineers don't seem to see it that way).

over engineering is anticipating for future requirements that aren't ever realized, or realized so far in the future that upfront cost outweighed the cost of putting it off for later. under engineering is not anticipating for future requirements that are realized before their cost outweighs the cost it would have taken to implement them upfront. somewhere there is a line, and on both sides you wasted money. if you perfectly engineered something, you spent the money optimally. in this industry, the idea you could perfect that is laughable. it's either over, or under engineered.

reading a blog post gives you fuck-all for insight into a project or team's actual budget and requirements. driving by and shouting "over engineered" is a very clear sign of lack of experience, and one of the most uninteresting things you can add to a conversation about a company _literally starting their own bank from nothing_.

so, OP, how would you under engineer your bank?

since you've resorted to grade school bullying, it's clear my point is beyond you, so I'll meet you at your level:

calling something over engineering reduces the problem to black and white thinking, which is incredibly uninteresting. let's not do that!

wow, I guess we agree, and you're still an asshole!

I never called it over engineered.

maybe by not building our own database

seems a bit like engineering for the sake of engineering

I'm all for it if it floats your boat, not sure that it's what I want from my bank though

where in the article does it say they built their own database?

it said they built a Datomic-like db on top of FoundationDB

sounds pretty cool, but was it really necessary...?

that's just how FoundationDB is architected; it's not quite the same as building your own DB. the database provides primitives that are safe to build abstractions like this on top of.

it's also not quite the same as using an off-the-shelf RDBMS, but they do a pretty good job of explaining why they made that design choice.

if anything, viewed through that lens, I'd say it seems quite pragmatic.