Quote:
There were update on 1st module. I want to publish only 1st module, so that the remaining 2 modules users are not impacted.
You are looking at the microservices architecture requirement here. Each service is a separate project, a separate process, and is hosted separately; an update in one service does not require redeployment for other services.
Quote:
Is it possible to minimise the downtime by this way?
Depends, if each service is independent, then at least you have localized the downtime to each service itself. How each service manages the downtime, that is a different story at all. There is likely a downtime to happen if you update the service;
the process needs to stop, update and restart.
Quote:
Or any other way we can minimise the downtime for an application?
You can try using blue-green deployments; where you start rolling out the updates to users gradually. This way, all the users are not impacted by the update. Some users continue to connect to and access the older version of your service. The updated instances are deployed and then traffic gradually starts to reach these pods;
Kubernetes reference[
^].
Quote:
Is there really something called as zero downtime?
Yes, there is a "logical" explanation of a zero downtime.
Quote:
If yes, then how can it be managed?
It works by using an orchestrator, so logically your service is always up but pods (processes) are created, update and destroyed in the background without your users knowing. I think this is a result of "networking" done right!
Then again, this depends on your infrastructure or platform and where you are hosting your service. If the platform supports this, then good, otherwise you might need to introduce other orchestrators (such as Kubernetes) to provide a zero-downtime.
Remember, for a good zero downtime, you need to use:
1. Stateless services
2. Out-proc database/session information (so users are not lost when the service updates)
3. Good orchestration service (Kubernetes?)
Good luck!