Cloud Computing

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.

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:

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.

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: Copy sudo nano /etc/nginx/sites-available/yourdomain.com Add:

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.