Live data from Hacker News

Cell-based architecture for resilient payment systems

americanexpress.io

31–40 of 66 posts

Re: Cell-based architecture for resilient payment systems

#31
post #30
post #13

Earlier quoted context omitted.

>To me that seems to create a window where it might route to the wrong cell due to an outdated routing state. But if the router sends to the wrong cell the cell will either send it back to be rerouted or it will fail and the router will try again (or report back the failure so upstream can try again I assume)

That would be the good case. But what if the cell doesn't know that, and it's holding, for example, a stale account number?

Generally with a credit card, or many banking systems more generally, because they predate computers, it's possible that a charge might be accepted even if there's no knowledge whether the money is in the account. As long as the person who was supposed to have paid is identifiable, the money is taken from their account anyway in the end, and if they don't have it, they get sued and their wages garnished, and if they also don't have wages, that's a small enough percentage of people that it's part of the cost of doing business.

Re: Cell-based architecture for resilient payment systems

#33

All i can see is a giant single point of failure called the Global Transaction Router.

GLBs aren’t SPOFs. They are typically deployed around the world redundantly, often using Anycast IPs or using DNS geographic and failover records, and are stateless. Think AWS Global Accelerator and Route 53 as an example. The architecture diagram is a high level simplification.

A large portion of DNS is outside of your control. You're relying on at least two third parties you have indirect relationships with in order to work. If you're outside of the standard TLDs you've got additional social factors that can control your resolution.

Granted. It works really well in practice. It should be noted we haven't actually had the world war the Internet was designed to survive. So we're not entirely clear on the semantics of operations in unusual and unexpected configurations. I would expect DNS to be the first shoe to drop there.

Re: Cell-based architecture for resilient payment systems

#34

As Reddit already pointed out, this is nothing novel.

“They reinvented Erlang OTP.” - Reddit

To be fair Elixir shows you can just use the BEAM if you want. If you need these semantics at this level there's very few reasons not to go this route.

Re: Cell-based architecture for resilient payment systems

#35
post #28

Earlier quoted context omitted.

GLBs aren’t SPOFs. They are typically deployed around the world redundantly, often using Anycast IPs or using DNS geographic and failover records, and are stateless. Think AWS Global Accelerator and Route 53 as an example. The architecture diagram is a high level simplification.

GLBs absolutely can be SPOF for certain kind of administrative mistakes.

That depends on your change control process

Re: Cell-based architecture for resilient payment systems

#36
post #8

American Express tech is some of the worst in the world among big companies. All of the value in the company is just in the branding. They put some work into the mobile app and the website, but other than that, its a facade.

BoA reauthorized an auto-payment card even with the card being expiration and uncorrected security code. I would call that authorized fraud by Bank of American.

This is why I find it best to declare a card stolen right before expiration or after.

Re: Cell-based architecture for resilient payment systems

#37
post #24

So you’re telling me these cells operate independently like distributed Ethereum nodes and L2s… got it.

Ethereum nodes are not independent, they are as interdependent as it's possible to be.

It's becoming a reliable heuristic that when somebody says "... got it", they probably didn't get it.

Re: Cell-based architecture for resilient payment systems

#40

Whole lot of nothing. This isn't about payment technologies, it's not about isolating transactions, it's about scaling the middle layer. What's worse it's not even explained what middle layer does. No info on how routing works, no info on data synchronization. Folks just learning Kubernetes and write extremely abstract stuff.

I agree, confusing and it seems like they are using the coined word "cell" to describe "container", but they really should say that instead of making up new words.
Post reply on HN