I'm not exactly sure how to ask this question but in my experience with NodeJS, which has a single thread and a process queue to manage async functions, you need to run an instance of your web server on seperate processes for each CPU thread - then load balance between each instance.
You can end up with 4 instances of the same software running, serving on 4 separate ports, being exposed on one port via the load balancer.
Typically, you'd use a service like PM2 to manage this process for you.
From my (basic) understanding, goroutines are not threads so my natural thinking wonders if that means Go needs to be run in the same way, multiple processes spanning for each CPU thread.
Is that the case? Or if I write a REST API using something like Gin, will Go automatically scale across CPU threads as the demand increases?
Virtually every Go web server is based on net/http and calls (eventually) http.ListenAndServe() on a http.Server. (In gin, router.Run() wraps this.) The documentation for http.Server explains that it:
calls Serve to handle requests on incoming connections.
http.Serve() does the real work of accepting connections,
creating a new service goroutine for each.
Goroutines are lighter than OS threads; it's possible to run many goroutines per thread. So, your app could potentially serve dozens (or hundreds or more?) of simultaneous connections on a single process.
And by default Go will use all available processor cores; you can set the GOMAXPROCS environment variable if you have some pressing need to not use all processor cores.
The GOMAXPROCS variable limits the number of operating system threads that can execute user-level Go code simultaneously. There is no limit to the number of threads that can be blocked in system calls on behalf of Go code; those do not count against the GOMAXPROCS limit. This package's GOMAXPROCS function queries and changes the limit.
So you don't need to mess with weird process managers like PM2 or supervisor; you can just start your server from a normal systemd unit, or as PID 1 in a Docker container, and enjoy (but reap your children).