distributed systems are usually for millions of users, not 12 users.
for your problem you can start by configuring nginx to work as load balancer and spin up 2nd VM with php app
for your problem you can start by configuring nginx to work as load balancer and spin up 2nd VM with php app
Also, philosophically, I guess, a "distributed" systems starts at "two machines". (And you actually get most of the "fun" of distributed systems with "two processes on the same machine".)
We're taught how to deal with "N=1" in school, and "N=all fans of Taylor Swift in the same seconds" in FAANGS.
Yet I suspect most people will be working on "N=12, 5 hours a day during office hours, except twice a year." And I'm not sure what's the reference techniques for that.
People opening a page in a browser that sends requests to a server is already a distributed system.
A monolith sending requests to a database instance is already a distributed system.
Having a metrics sidecar running along your monolith is already a distributed system.
True, of course.
And even a simple set like this brings in "distribution" issues for the app developper:
When do you connect ? When do you reconnect ?
Where do you get your connection credentials from ?
What should happen when those credentials have to change ?
Do you ever decide to connect to a backup db ?
Do you ever switch your application logic to a mode where you know the DB is down, but you still try to work without it anyway ?
Etc..
Those examples are specific to DBS, but in a distributed system any other services brings in the same questions.
With experience you get opinions and intuitions about how to attack each issues ; my question is still : "should you need to point a newcomer to some reference / book about those questions, where would you point to ?"
Here you go: http://bofh.bjash.com/