Cloud Computing

Cloud Computing / 19 Sep 2026 / 5 min read

Wildcard Subdomains on Cloudflare Workers: Routing and TLS Boundaries

A hostname such as demo.instara.app can reach a Cloudflare Worker through one wildcard DNS record and one Worker Route. A deeper hostname such as web.demo.instara.app can resolve through the same wildcard DNS record and still fail before the Worker runs because the edge certificate does not cover that hostname. That distinction matters because three independent mechanisms participate in the request: DNS resolution | v Worker Route matching | v TLS certificate coverage They all use wildcard syntax, but they do not have identical matching rules.

Cloud Computing Cloudflare Workers

Cloud Computing / 19 Sep 2026 / 6 min read

WebSocket Lifecycles in Cloudflare Workers: Upgrade, Coordination, and Hibernation

A Cloudflare Worker can terminate a WebSocket connection directly. The harder architectural question appears after the upgrade succeeds: where does connection state live, which process coordinates multiple clients, and what remains valid when the runtime is no longer in memory? Those are separate boundaries: HTTP request | | Upgrade: websocket v Worker | +-- one independent connection | +-- shared room / session / presence | v Durable Object | v optional hibernation Treating all of them as “WebSocket support” hides the behavior that matters most in production.

Cloud Computing Cloudflare Workers

Cloud Computing / 04 Sep 2026 / 11 min read

Design Dead-Letter Queues for Poison Messages

Retries are useful when a failure is temporary. A database may be unavailable for a few seconds, a downstream service may return an overload response, or a network connection may disappear and recover. Retries become harmful when the message itself cannot succeed. A malformed payload, an unsupported schema version, a reference to permanently missing data, or a deterministic application bug can make the same message fail on every delivery. If the broker keeps returning that message to consumers indefinitely, the system spends capacity repeating work that has no chance of succeeding.

Cloud Computing Message Queues

Cloud Computing / 02 Sep 2026 / 5 min read

Load Shedding and Overload Protection for Cloud Services

Autoscaling is useful, but it is not instantaneous. Traffic can rise faster than new instances start, a dependency can slow down, or a retry storm can multiply work. When demand exceeds safe capacity, accepting every request can make the entire service slower until almost nothing completes. Load shedding is the deliberate rejection or degradation of work to keep the system inside a recoverable operating range. Overload is often a queueing problem Imagine a service that safely handles 200 concurrent requests. A downstream dependency slows from 50 ms to 2 seconds.

Cloud Computing Reliability

Cloud Computing / 02 Sep 2026 / 5 min read

Graceful Shutdown and Connection Draining for Cloud Services

Cloud services are stopped routinely: deployments replace instances, autoscalers remove capacity, hosts reboot, and schedulers reschedule workloads. If a process exits immediately when it receives a termination signal, in-flight requests can fail even when the service is otherwise healthy. Graceful shutdown is a small lifecycle protocol: stop taking new work, allow useful work already in progress to finish within a deadline, then release resources and exit. Separate readiness from process health A process that is shutting down may still be alive but should no longer receive new traffic.

Cloud Computing Reliability

Cloud Computing / 01 Sep 2026 / 4 min read

Propagate Timeout Budgets Across Cloud Services

A request that crosses several cloud services does not have one timeout. It has a chain of deadlines: client, edge proxy, application, database, and downstream APIs. When those limits are configured independently, an upstream service can give up while downstream work continues consuming connections and CPU for a response nobody will use. An end-to-end timeout budget gives the request one bounded lifetime and lets each hop consume part of it.

Cloud Computing Distributed Systems

Cloud Computing / 01 Sep 2026 / 5 min read

Idempotent Event Consumers for At-Least-Once Delivery

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.

Cloud Computing Events

Cloud Computing / 01 Sep 2026 / 5 min read

Designing Stateless Web Services for Horizontal Scaling

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:

Cloud Computing DevOps

Cloud Computing / 01 Sep 2026 / 3 min read

Design Circuit Breakers for Cloud Service Dependencies

When a downstream service is failing, continuing to send every request can waste threads, sockets, and latency budget while increasing load on the unhealthy dependency. A circuit breaker temporarily fails calls fast after failures cross a threshold. Understand the three states A typical breaker is closed while calls flow normally. It moves open after a configured failure policy is exceeded. After a recovery interval, it becomes half-open and allows a limited number of probes. Successful probes close the circuit; failures open it again.

Cloud Computing Resilience

Cloud Computing / 01 Sep 2026 / 5 min read

Blue-Green Deployments for Safer Zero-Downtime Releases

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.

DevOps Deployment

Cloud Computing / 06 Sep 2025 / 3 min read

Reverse Proxy with Nginx and Go for Microservices

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

DevOps Nginx

Cloud Computing / Updated 02 Sep 2025 / 2 min read

Using Nginx as a Reverse Proxy for a Go Application

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.

DevOps Golang