Which project architecture to choose?

Question

Node.js

We need advice from an experienced person on how best to organize the architecture of the project.
There are several incoming web servers that must have the same logic and models, in addition, all this must connect to a billing server to which it will constantly manipulate information.
1. api.example.ru - API for terminals and other payment systems, where the user will be checked and the balance will be replenished (jwt)
2. app.example.ru - API for the application of users from the web for iframe (jwt)
3. web.example .ru - landing page for users with a personal
account 4. biz.example.ru - simple landing page with mail subscription
5. partner.example.ru - API for a partner application (I think it will be written in Vue Native) (jwt)
6. console.example.ru - admin part from where everything should be managed by admins and operators
There were several ideas:
1. Link folders with common logic into projects, but this is somehow not right
2. Make one monolithic application where services will be distributed across domains in routes
3. Make one Middleware Server where all the above pages will be connected . I
just have no experience in large projects, I will be glad for any advice.

Answer 1

make a set of microservices and put them behind a proxy ( nginx / traefik ) for convenience, you can pack everything into docker and there will be easy delivery and easy updating :)

Answer 2

For all users - landing on www.example.com.
All APIs www.example.com/api/version/whatever
Now why should you do it this way?
The domain should be set to www for a simple reason - subdomains are cached for a shorter time, and therefore the move will be less painful.
It is most convenient to do landings and rubbish inside catalogs. For example, you have a link www.example.com/megapartner that can be shared on social networks, forums, etc. All this increases the value of your domain for search engines. If you use subdomains, then this weight will be blurred, because. search engines will consider everything different sites.
Authorization and user management should be unified. You should not make 20 different places for which you need to log in 100 times. Roles have long been invented for this. I recommend that you immediately implement the login through the same Facebook / Google / OK / VK, etc.
General authorization provides a huge number of advantages, for example, it facilitates support at times, it allows you to know the context for performing actions.
One domain facilitates the user experience, as he doesn't have to memorize a dozen different pages.
Well, the additional benefits of a reverse proxy are that you can always set up a redirect, cache something, show the correct page if one of the services has fallen off.
Behind the proxy, everything should be divided according to purpose, each project should be kept in different repositories, etc. This can significantly simplify development, for example, you can give some kind of landing page for processing simply by giving access to the repository.
If you really want to stubbornly and play devops, break it into 100500 microservices, shove everything inside kubernetis with some kind of istio. There will be a beautiful architecture with containers and buns.
When you've played enough, take a regular nginx, write a simple reverse configuration and it will work like clockwork for years.