Cloud Computing on Nalar

Blue-Green Deployments for Safer Zero-Downtime Releases

Tue, 01 Sep 2026 00:00:00 +0700

A blue-green deployment keeps two production-capable application environments. One serves live traffic while the other receives the new release. After validation, traffic is switched to the candidate environment.

The pattern can make rollback fast, but it does not automatically make a release safe. Database changes, background jobs, caches, and external side effects can still make an old version incompatible with the new state.

The basic release sequence

Assume blue is currently live and green will run the new version.

Designing Stateless Web Services for Horizontal Scaling

Tue, 01 Sep 2026 00:00:00 +0700

Horizontal scaling adds application replicas instead of making one machine larger. The load balancer can send each request to any healthy instance, which only works reliably when instances do not depend on unique local state.

“Stateless” does not mean the application has no state. It means durable or shared state lives outside an individual process so any replica can continue serving the workload.

Identify hidden local state

A service may appear stateless while depending on:

Idempotent Event Consumers for At-Least-Once Delivery

Tue, 01 Sep 2026 00:00:00 +0700

Many queues and event brokers provide at-least-once delivery: a message that has been accepted can be delivered again when acknowledgements are lost, consumers crash, visibility timeouts expire, or the broker retries after uncertain outcomes.

Duplicates are therefore not exceptional. A robust consumer should assume that the same logical event can arrive more than once.

Why duplicates happen

Consider this sequence:

a consumer receives an event;
it updates the database successfully;
the process crashes before acknowledging the message;
the broker makes the message visible again;
another consumer receives it.

The broker cannot know that the database update happened. Redelivery is the safer choice.

Reverse Proxy with Nginx and Go for Microservices

Sat, 06 Sep 2025 00:00:00 +0700

As an application grows, splitting it into smaller services can make independent deployment and scaling easier. For example:

Product service on port 8080
Blog service on port 8081

Users should not need to know those internal ports. An Nginx reverse proxy can expose both services under one domain and route requests by URL path.

1. Configure the Nginx Reverse Proxy

Create a site configuration:

$el.innerText = 'Copy', 2000)" class="absolute top-2 right-2 bg-neutral-700 text-white text-xs px-2 py-1 rounded opacity-0 group-hover:opacity-100 transition-opacity" > Copy

sudo nano /etc/nginx/sites-available/yourdomain.com

Add:

Using Nginx as a Reverse Proxy for a Go Application

Sat, 24 Aug 2024 00:00:00 +0700

A Go web application often listens directly on an application port such as :8080. If you want users to access it through a normal domain on port 80 or 443, you can place Nginx in front of it as a reverse proxy.

Using Nginx in front of a Go service provides several benefits:

Client requests reach Nginx before being forwarded to the Go application.
TLS termination can be handled at the proxy layer.
Multiple application instances can be load balanced.
Static assets can be served separately when that architecture makes sense.

This guide shows a basic setup.