Microservices architecture with Django

I have some questions about creating microservices with Django.

Let's say we have an online shop or a larger system with many database requests and users. I want to practice and simulate a simple microservice to learn something new.

We want to create a microservices-based system with the following components:

1. A Django-based microservice with its admin panel and full functionality (excluding DRF).
2. One or more microservices with a React/Angular frontend.
3. Several additional microservices to separate functionalities.
   I'm unsure about the architecture. Let's assume we want to manage data using the Django admin panel.

The simplest solution would be to add DRF to the first microservice and extend its functionality (REST app) - instead of creating different services (3.).

1. But what if we want to separate functionality into different microservices?
2. Should the microservices in point 3 be connected to the same database and treated as different Django projects (with DRF)?
3. Can we use GoLang, FastAPI, or Java Spring for the third microservice? If yes, should all models be duplicated and registered in the first microservice?
4. Alternatively, is there a better way to approach this?

It would be great to hear your perspective and methods on how to proceed with this.

Have a wonderful day!

First a quick summary of Microservices vs Monolithic apps pros and cons (this is important).

Microservices:

[ PROS ]

• scalability (they scale independently)
• flexibility (each microservice can use its own stack & hardware setup)
• isolation (the failure of one microservice does not affect another, only its service fails.)

[ CONS ]

• Complexity (so much infrastructure to setup and maintain at every layer)
• Data consistency (each db is independent so makink sure consistency is maintained is added complexity)
• Distributed system challenges ( latency/fault tolerance and testing is much harder)

Now for your questions:

1. separating functionality into different microservices.
   That is what apps in a Django project are for, and is a core principle of software engineering, separation of concerns can still be applied in a monolithic application.
   When discussing microservices, the questions should be about what benefit would it bring at the cost of complexity, such having a service that does pure gpu computation, perhaps would benefit from being a microservice running in on an optimized language and system with access to GPUs. I would even argue you should only transition to using microservices, when you have explored all other solutions, and have composed an irrefutable argument to do so with the team.

2. Should microservices be connected to the same DB.
   Microservices should have their own db, see Isolation. otherwise it's the same as just using a monolithic app with extra complexity and no benefit.

3. Can you use a different stack, and should duplicated models be registered. This again comes under a missunderstanding of what a microservice is. Your microservice should encapsulate the minimum amount of data it needs to function independently.

4. Alternative: Design your Monolithic application very well, separate out your concerns and business logic in a de-coupled design, even if it's a monolith. you have to have the mindset of: "if I want to swap this functionality for a microservice, how easily will it be to rip it out, what is the coupling, etc...) A good design leads to scalability and maintainability which is most important. It also allows other people to contribute their expertise on a subset of the project, without needing to know the whole.