The goal is to be able to have thousands of concurrent connections without interference and timeouts.
It's a good goal, but not one I can provide an answer to here and now. Again, there are many many many variables. For one, how much load exactly? What kind of budget? Are you solely trying to meet a concurrency goal? Or HA for uptime/failover? Do you currently have this traffic? Is it bursts or constant?
I'm not going to write a thesis here, but there are many ways to do load balancing as you describe. Actually - my statement about need three servers is wrong. It's perfectly possible to do this via DNS, anycast, etc.
Loading balancing at core is splitting traffic to a "pool" of servers, to balance load as the name implies. You don't need a reverse proxy to do this, though it's a pretty common method. There's other ways, usually at lower OSI layers that route the actual traffic vs request.
Some users access the files from server#1 and some other users from server#2. As I can see nginx has the ability to do that based on location, so if one server is in USA and the other one in EUROPE, it will benefit each user respectively.
You need something to route requests to these servers. How do you determine who goes to US, who goes to EU? A load balancer/proxy can do this, using IP for Geolocation. You could also anycast the same IP, so users get routed to the closest origin, or use DNS, to serve different records.
Load balancing is something that really confuses me...some people say that you need multiple servers, but by multiple servers, they mean different ports, or another webserver on the same server... could you please clarify more on that topic? How can I achieve load balancing with nginx?
It's really not a "I have NGINX, how to load balance?" kind of question. You can setup a basic configuration with NGINX, sure. But if you'd like it to work properly, and well, there's quite a bit you'd have to plan for. Load balancing literally means distributing requests ("load") across multiple backends. These could be DNS servers, webservers, kube clusters, or physical servers. In your case, you'd need the latter, as you want them geographically separate.
Load balancing doesnt have to be done directly from plesk, can't it be configured from the shell access (ssh)?
Yes, but you'd need to make your "Plesk" servers work with load balancing. There are lots of implications and it's an
extremely complex topic. How do you route traffic? How do you handle failover scenarios? How do you handle replication (you can't just "lsync/rsync" your database) or data conflict/mismatch? How do you handle user sessions?
Frankly, I'd really, really recommend:
1. Hiring somone
2. Evaluating whether you actually *need* load balancing. A 1 core, 1 GB VPS can serve 5-10k rqs of static HTML files. You can certainly get one server serving hundreds, thousands, of connections if it's tuned and set up optimally.