Ship without downtime: three patterns every product team should know

Customers should never notice that you released something, unless it is a feature they wanted. Three patterns make that possible, and none of them need a big engineering team to understand.

Blue-green deployments

Instead of one live environment, you run two identical ones. Call them blue and green. Blue is live and serves every customer. Green is idle. You deploy the new version to green, not on top of what customers are using.

Then you test green privately. Can people log in? Can they add to basket? Does checkout reach the payment provider? Do the health checks pass? If something is broken, nobody notices, because everyone is still on blue.

When green looks good, you do not deploy again. You move the traffic: the load balancer starts sending requests to green. If an error appears, you send traffic back to blue, which is still running. Rollback takes seconds rather than an anxious hour.

Background workers

Some work is slow: sending emails, generating reports, resizing images, calling an external service that is having a bad day. If that work happens while the customer waits for a page to load, a slow service makes your whole product slow, and timeouts turn into failed requests.

The fix is to hand slow jobs to background workers through a queue. The customer gets an immediate response (‘Your report is being prepared’), and the worker does the job a moment later, retrying if needed.

The transactional outbox

There is a trap here. If your code saves an order to the database and then puts a ‘send confirmation email’ job on a queue, a crash between those two steps loses the job. The order exists; the email never goes.

The transactional outbox avoids this by writing the job into an ‘outbox’ table in the same database transaction as the order. Either both are saved or neither is. A separate process reads the outbox and passes jobs to the queue. Add visibility timeouts so a job picked up by a worker that crashes becomes available again, and make jobs safe to run twice.

Why this matters beyond engineering

These patterns are promises to customers: we will not take the site down to update it, we will not keep you waiting for slow work, and we will not lose what you asked us to do. Treat those promises as requirements, the same as any feature.