"Microservices perform better, especially when written in Go."
Nonsense.
Nonsense.
If you have a substantive point to make, make it thoughtfully; if you don't, please don't comment until you do.
Microservices can lead to better performance by making for smaller, more clearly defined codebases, fewer unnecessary imports, and so on. They can also be easy to scale, because you can scale specifically that one component (e.g. identity management) by moving it to a separate database server.
We use microservices, and we have probably close to 2TB of MySQL database, but because we have our services and their database schemas cleanly separated, we can break that up into a set of databases which all fit into memory and one database which, being basically append-only, doesn't need to access historical data and so doesn't need to fit entirely in RAM.
It also lets us easily look at our cluster stats and see where bottlenecks are, by easily seeing which servers or services are under load.
We do pay a penalty for this; layers of indirection, network latency, protocol overhead, serialization/deserialization, and so on, but designing our systems like that from the start lets us tackle those problems at the start and account for them in our design.
Here are a few references that leap to mind (I keep the first printed out and pinned right next to my monitor).
https://gist.github.com/jboner/2841832
https://www.quora.com/What-are-some-mind-blowing-facts-about...
This is a ridiculous comparison though. When have you ever seen a situation where a micro service was accessed over the network to fetch something that would have been in L1 cache? And yes, having a value "in memory" is faster, but in most cases these days things aren't "in memory", they're "in memory in memcached, somewhere in the cluster, probably not on the local server so you have to go over the network anyway".
Just out of curiosity though, I tested on our network. Our RTT between servers is less than half a millisecond. Our fastest service can get a cached reply back to the calling service in 35ms, whereas many calls are >100ms and some are much longer (e.g. initial login calls). It would take a lot of external login calls to noticeably (to the user) increase even the fastest service.
We also use Redis and memcached, and spread those across other services. Excluding specifically HTTP overhead and just looking at network latency, a few memcached calls which hit non-local servers in the cluster cost us as much in latency as one HTTP call would.
One point of context I'd like to inject here is that chatter between AuthN and a host app is pretty minimal. Aside from executing admin actions like locking an account, the main dependency is fetching a public key to verify JWTs. This public key can be cached using a standard key fingerprint, which means it only needs to happen once per process.
Architecture does matter, and I've been pretty happy with how AuthN's boundary has played out.