Hi Niteesh, typically for your microservices, you want to have 1 database instance per microservice. There are a lot of advantages to this approach in terms of improved resiliency, simplicity etc. It's also better to use a managed database service to run your databases when you are relying on them in production. Running databases locally with docker-compose is typically better suited for your integration testing and for data that you don't necessarily care about if it gets lost. I hope this helps!

@@Tutorialedge Iam using droplets for docker....so can I run MySQL container inside the droplet to store the data ...?? My another question is that ,you have said, "1 database instance per Microservices" but if I want to follow the relational model then this approach will be good ??

Thankuu for replying me 😄

Hey Amal! I should have used v2 here, but in fairness the Go application was an arbitrary example that I needed to create in order to highlight how you could use Docker-compose for your Go apps. I hope this helps :)

Hi Cyberbit, so you may be able to create multiple networks for these things in docker compose, however this isn't the approach that you should take for production applications. When developing production systems, you would typically rely on something like Kubernetes with Istio to manage the networking between your multiple microservices. These are specialised tools that give you the option to define fine-grained networking rules that can seriously improve the security of your services. I will be doing a premium course on Kubernetes in the near future on my site so stay tuned!

@@Tutorialedge Thanks Eliot for explaining it. A course, Yes, that would be great. Looking forward to it. 👍

Go extension by google