{
  "id": 105899,
  "title": "Episode 5 — Who Gets to Flip the Switch",
  "url": "https://urgent.news/2026/08/03/episode-5-who-gets-to-flip-the-switch",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-03T23:36:16.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/surajrkhonde/episode-5-who-gets-to-flip-the-switch-2d9g"
  },
  "original_language": "en",
  "account": "In the 5th episode of the series, the discussion revolves around the challenge of deploying new software versions to production without causing downtime or issues for users. The junior engineer proposes a simple solution: stop the old container and start the new one, but the senior engineer warns that this approach can lead to a critical gap of downtime where no container is running. This gap can result in failed requests and negatively impact the user experience, especially for services like a payment API where downtime directly translates to financial loss and user dissatisfaction.\n\nThe senior engineer introduces the concept of \"overlap\" as a safer deployment strategy, suggesting that both the old and new versions of the software can run simultaneously, allowing for a smooth transition without downtime. Two popular deployment strategies mentioned are blue-green deployment and rolling deployment. Blue-green deployment involves maintaining two identical production environments, with one (Blue) serving live traffic and the other (Green) idle. The new version is deployed to the Green environment, which is then switched to production, instantly redirecting all traffic from Blue to Green. If issues arise, the switch can be quickly reverted back to Blue.\n\nRolling deployment, on the other hand, gradually replaces instances of the old version with new ones in a controlled manner. For example, in a setup where multiple instances of an app are running behind a load balancer, instances are replaced one at a time, ensuring that some requests are served by the old version while others are served by the new version. This method allows for monitoring and verification of the new version's performance and stability before fully transitioning to it. Both blue-green and rolling deployments require that the old and new versions can coexist safely, meaning they must handle data and operations in a compatible manner to avoid conflicts.\n\nThe senior engineer emphasizes the importance of ensuring that both versions can operate together without issues, as any discrepancies can cause unexpected behavior and errors during the deployment process. The episode highlights the trade-offs between different deployment strategies, balancing the need for simplicity and cost with the potential risks to application stability and user experience.",
  "summary": "Week 3. \"The artifact is sitting in the registry. Somebody still has to actually run it. Who, and how?\" Previously Developer ↓ Runner ↓ Cache ↓ Artifact Today ↓ Deployment Junior Engineer: So the image is built, tagged, sitting in the registry. What's the simplest possible way to actually get it running in production? Senior Engineer: The simplest way is also the most dangerous way. Want to guess…",
  "key_points": [
    "Junior engineer proposes stopping old container, starting new one.",
    "Senior engineer warns of critical downtime gap.",
    "Senior engineer introduces overlap strategy."
  ],
  "editors_take": "The discussion highlights that deploying new software versions requires balancing simplicity and cost with potential risks to application stability and user experience, particularly for services with high availability requirements.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}