Going distributed, and the law
A distributed system is several machines, called nodes, working over a network.
Why go distributed
Some apps are distributed by nature: users on their own phones must talk over a network, and cloud services call each other. Other reasons: surviving a dead machine, load too big for one machine, servers near users, adding machines only at busy times, special hardware like GPUs, laws that keep residents' data in their country, and running jobs where clean power is plentiful.
The cost of distribution
A network call is far slower than a local function call, and it can fail. After a timeout you don't know if the other side did the work, so a blind retry can do it twice. Finding slow spots needs tracing. If each service has its own database, keeping them consistent is your problem. A simple program on one big machine often beats a cluster.
Microservices and serverless
A microservice has one job, a network API, and one owning team. Each keeps its own database, and the main gain is that teams can work without waiting on each other. The price: many services to run and test, and API changes that break callers. Serverless runs your function on demand and bills only while it runs, but has time limits, limited runtimes, and slow cold starts.
Cloud vs supercomputing
Supercomputers run long science jobs for trusted users on closely linked nodes. When a node fails, they stop and restart from a saved checkpoint. Cloud services serve strangers, so they need isolation and encryption, and they must keep running through failures.
Data, law, and ethics
Laws like GDPR give people rights over their data, including deletion, which is hard in append-only logs and derived data. Stored data can leak, bring fines, or be seized and used against users, so keep only what you need. PCI and SOC 2 audits apply too.
Remember
- Distribute only when you must; one machine is simpler.
- A timeout does not tell you what happened.
- Microservices solve a team problem.
- Data you keep is a risk, not just an asset.