See this previous post on Microservices shared front end aka How does servicestack find services? on starting with a Monolith then split out Services when needed, use the Service Gateway to enable loose-coupling for inter-process Service calls, and you’d typically want to use JWT for authentication.
As to the correct design, you should almost always start with a Monolith first, but design your App so it can be easily split up, e.g. maintain proposed Microservice implementations in different decoupled .dll’s where only inter-coupling between them should be sharing the same DTOs & using the Service Gateway for communication, which will allow you to easily extract the Service implementation into a different AppHost that can then be accessed remotely.
So whilst it’s advisable to be designing your monolith “for Microservices” so it can be easily split out into different microservices, doing so adds more complexity, latency & performance & maintenance overhead, deployment overhead, lower productivity, multiple PoFs, etc so you should have very clear tangible value for doing so, it need not only be technical, e.g. a valid reason for a Microservice is there are different teams working on them who’d prefer to develop & release on their own cadence.
Definitely don’t just add infrastructure dependency if you don’t know you absolutely need it. Each adds an additional PoF. It should be evident when you need features like a MQ, e.g. for facilitating requests that are no longer suitable to be executed synchronously, like long-running time-decoupled async oneway operations.
Talking about system design in abstract is not going help with your decisions. The question you should be continually asking is what benefit will I get from splitting out into a remote host? and does it justify the additional overhead? e.g. Why are you splitting your API Gateway from your Monolith, it already looks like it was adopting the role of an API gateway?
Do all requests need to go through a monolith, e.g. can your Services be called directly. If you adopt JWT only the monolith needs to be concerned about Authentication & issuing new tokens which can embed what roles/features (Audience) each user is allowed to access to, each Service then only needs to validate the JWT & check that they’re allowed access to the feature/Service.
Others on here may have different recommendations, but mine is always going to be design your systems simplicity-first where the correct number of Microservices being the minimum number required.
