Solana's 'Decentralized' Infrastructure Exposed as Classic Web2 Architecture
Description
A simple black-and-white architectural diagram ironically labeled 'solana infrastructure' at the top. The diagram illustrates a standard, centralized Web2 client-server model. On the left, a 'client' laptop icon sends a 'write' request to an 'application node' (server icon) and receives a 'read' response. The application node, in turn, communicates with a 'Master database' for writes. This master database then performs 'Replication' to a 'Slave database,' which is used for reads by the application node. This diagram is humorous and critical because it deliberately misrepresents a classic, centralized database architecture - a setup familiar to any experienced web developer for decades - as the infrastructure for Solana, a blockchain platform famous for its claims of high decentralization and performance. The joke lies in the stark contrast between the hype of Web3/blockchain technology and the mundane reality of traditional, centralized systems. For senior engineers, this is a biting satire on how some of the most hyped 'decentralized' projects in the crypto space may, under the hood, rely on conventional, centralized choke points, completely undermining their core value proposition
Comments
32Comment deleted
Ah, Solana's groundbreaking architecture: reinventing the 1990s-era MySQL primary/replica setup but with added consensus theater and a token. It's not a single point of failure if you call it a 'validator.'
Solana’s secret sauce: rebrand a master - slave MySQL pair as “Proof-of-History” and call the binlog a blockchain
Nothing says 'decentralized future of finance' quite like a good old-fashioned master-slave database architecture diagram - because even at 65,000 TPS, Solana still needs somewhere to store those transaction receipts when the validators aren't having their weekly timeout party
Turns out 'web-scale decentralization' was a read replica all along - at least when Solana goes down, the postmortem only needs one diagram
Ah yes, the classic 'master-slave' database architecture diagram - because nothing says 'modern blockchain infrastructure' quite like terminology that would get you sent to HR sensitivity training faster than a production deployment on Friday afternoon. At least Solana's infrastructure is more reliable than their network uptime during NFT mints
Solana infrastructure: write to master, read from replicas; consensus is whatever replication lag and the on-call DBA decide - aka Proof-of-Read-Replica
If your “chain” routes writes to one primary and calls the rest “replication,” that’s not Byzantine consensus - it’s a read‑replica cluster with better marketing
Solana infra: writes to master, reads from slaves. Because 50k TPS is just MySQL with blockchain branding
pfft who needs a replication anyway? Comment deleted
@RiedleroD Comment deleted
nsfw isn't forbidden, but I'll remove it I guess Comment deleted
That worse than nsfw Comment deleted
gay nsfw is still just nsfw Comment deleted
ah yes, master & slave. good times when these words were still used. good times. Now every time I want to checkout master, I have to check if it's main first. Comment deleted
Oh this is so annoying Comment deleted
Whoever used this terms in the first place was crazy Comment deleted
"Hmm, this device controls every action of the other one. What should I call it?" Master is one of the best options possible. Comment deleted
The problem is it does not control (as it is performed by e.g. Kubernetes controller node) but does the work on its own, and the replica node repeats the same actions. Does it look like a master-slave relation to you? For me "origin-replica" (for sql) or controller-worker (for distributed systems) makes way more sense here. The only thing about the original technology is everybody's used to it, but it doesn't mean we should not fix the old error. Comment deleted
dunno abt SQL tbh, but in many other standards, the terminology does make sense. Comment deleted
Could you name of few? Comment deleted
USB standard - if the devices have a master/slave connection (p2p exists as well afaik), one device does control the other pretty much entirely, as far as the USB standard allows. E.g. when file sharing, one device controls which files are copied, etc. Same with bluetooth afaik. In the gaming space, some models could be called master/slave, though server/client is usually preferred & makes more sense anyway. Uhh other than that, I don't have any good examples. I'm probably forgetting a lot of stuff though. Comment deleted
> though server/client is usually preferred & makes more sense anyway. Funny enough, if I am dining in a restaurant, who controls the food flow — me the client or my server? :) However with bluetooth or usb master-slave naming sounds traditional, but not very obvious or logical. Comment deleted
you control what the server then agrees to serve Comment deleted
Yes, this sounds right. Comment deleted
spam is still forbidden Comment deleted
please don't though Comment deleted
Why app node always go into master. Where is read scalability Comment deleted
That is exactly why IDE was deprecated long ago! 😁 Comment deleted
The opposite of master doesn't have to be slave Comment deleted
Could be mirror node, backup node, standby node or following node etc Comment deleted
what? you write firectly to master but only rrad from slave? wtf is this aarch? it just copies from the master so whats the point ? Comment deleted
If you have many complicated reads and only a few occasional writes this architecture actually makes a lot of sense. Also the R/W node can be set up in your HQ or somewhere nearby, while the RO nodes are in every data center. The point is latency and resource usage optimization. Comment deleted