Architecture for Zero Downtime in Critical Applications

Many companies recognize the situation NordFinans faced: A massive monolithic application that had grown unwieldy. The distribution process was manual, slow, and characterized by high risk:

Maintenance windows: Updates required planned downtime, typically scheduled for late evenings. This created frustration for users who expected 24/7 services, and wore out developers who had to work nights.

"Deployment Fear": Because each rollout was a major operation, they were postponed as long as possible. This led to a vicious cycle of enormous code conflicts and increased probability of errors.

Inefficient scaling: During traffic peaks, the entire monolith had to be scaled up, even if only a small part of the system was under pressure.

To meet today's availability requirements, the company set three absolute technical requirements:

GitLab (Self-Managed) was chosen as the primary platform for internal source code and infrastructure.

Why: GitLab offers a complete package with source code, CI pipelines, container registry, and security scanning (SAST/DAST) in one closed ecosystem.

Kubernetes integration: Via GitLab Agent, the platform team can control access granularly without exposing sensitive access keys to developers.

Public SDKs and partner integrations live on GitHub.

Why: GitHub is the industry standard for open-source.

GitHub Actions: Here, Actions are used to run public tests and publish packages to registries like NPM, PyPI, and Packagist.

To avoid fragmentation, GitLab functions as "Source of Truth". Code is automatically mirrored to GitHub, so developers only deal with one dashboard, while the code lives in two places.

ArgoCD was implemented to synchronize the state in Git with the state in the Kubernetes cluster.

Pull-based model: Instead of the CI server "pushing" changes to the cluster (which requires the CI server to have admin access to prod), ArgoCD "pulls" changes from a separate manifest repo.

Security: This means the CI system never has direct access to the production environment, which eliminates a massive attack surface.

1. CI (Build): Developer pushes code. Pipeline runs tests, builds Docker image, and scans for vulnerabilities.
2. CD (Update): If the build succeeds, the CI job updates the version tag in a separate manifest repo.
3. Sync: ArgoCD detects the change, calculates the difference, and rolls out the change in a controlled manner in Kubernetes.

The default behavior of Kubernetes is a "Rolling Update", but the default settings are often too aggressive for critical applications. The strategy must be adjusted to guarantee capacity:

The most common error when transitioning to Kubernetes is ignoring the application's lifecycle. When a pod is about to die, two things happen simultaneously (asynchronously):

1. Kubernetes removes the pod's IP from the load balancers.
2. Kubernetes sends SIGTERM to the container to stop the process.

The problem: Processes like Nginx, Go binaries, or Node.js often stop faster than it takes for Kubernetes to update the network rules throughout the cluster. The result? Traffic is sent to a pod that has just died. The user sees "502 Bad Gateway".

Liveness Probe: "Am I alive?". Checks if the process is running. Best Practice: Should be simple. Don't check database connection here! If the database goes down, all pods will restart simultaneously in an eternal loop.

Readiness Probe: "Am I ready to receive traffic?". Best Practice: Check if the application can actually do work (e.g., db connection ok, cache warm). If this fails, the pod is taken out of the traffic flow without being restarted.

Are we changing a column name from address to billing_address? We add the new column but keep the old one. We roll out the code. Now both columns exist.

The application is updated to write to both columns but read from the new one. A background script moves old data.

When we're sure all pods are running new code that uses billing_address, we remove the old column in a final migration.

In a dynamic cluster, you can't rely on .env files that change on disk. All configuration must be injected as Environment Variables from Kubernetes ConfigMaps and Secrets.

• Node.js/Python/Go: Read directly from the environment (process.env / os.environ).
• PHP: Ensure that configuration cached during build time doesn't contain hardcoded paths that change in production.

An often overlooked trap is asynchronous jobs (RabbitMQ, Redis, Kafka). When a new version is deployed, there may be jobs in the queue that are serialized with the old code structure. If a worker with new code picks up an old job payload, the application may crash.

Solution: Use versioned queues, or ensure that job payloads are always backward compatible. For major changes ("breaking changes"), the queue must be drained before updating.