{
  "id": 6248094,
  "title": "We Picked the Region Because It Was the Default in the Dropdown",
  "url": "https://urgent.news/2026/09/08/we-picked-the-region-because-it-was-the-default-in-the-dropdown",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-08T07:00:50.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/serguey_shinder_4ab9b87b1/we-picked-the-region-because-it-was-the-default-in-the-dropdown-5b4a"
  },
  "original_language": "en",
  "account": "The proof of concept took just an afternoon to create. An account was made using whatever region was selected by default, a few services were deployed, and the setup was presented to a stakeholder who approved of it. A year and a half later, that same region hosted the production database, object storage, queues, and four years' worth of regulatory data, with no one having made a decision about it at any point. The repercussions unfolded gradually, each one minor enough to ignore. Most users were located on the other side of the world, adding roughly a hundred and forty milliseconds to every round trip. Since the application communicated frequently rather than being slow, this resulted in web pages that users described as sluggish, but no one filed a ticket about it. Later, legal inquired during an unrelated review about where customer records were physically stored, and the truthful answer required explaining that no one had made a choice. A managed service that was desired was not available in that region, so a self-managed older version was used instead, leading to the operational work that the platform was intended to prevent. The analytics team subsequently set up their warehouse closer to headquarters, resulting in nightly data transfers across regions that continued indefinitely. What makes region selection more complex than it initially appears is that it is one of the few choices that truly impacts a system in an environment that markets itself as elastic. Compute resources can be easily shifted. Stateful services require an outage, a migration project, and a real risk of data loss before they can move. By the time someone is a senior enough to worry about the answer, changing it would cost more than simply living with it, so that's what they do, and they refer to it as their architecture. In the end, I now view a few choices as one-way streets and insist they receive five minutes of deliberate thought, even during a prototype, especially concerning region and data residency, account and subscription boundaries, the identity provider, and the primary datastore. These are not decisions with wrong answers; they are the ones that start out being fine, become permanent without anyone realizing, and later need to be defended by people who were not present during the original decision-making process. This is the work of Serguey Shinder.",
  "summary": "The proof of concept took an afternoon. Somebody created an account, accepted whatever region was preselected, deployed a couple of services and showed it to a stakeholder who liked it. Eighteen months later that region held our production database, our object storage, our queues and about four years of regulatory retention, and nobody had ever made a decision about it. The consequences arrived…",
  "key_points": [
    "Default region selected for proof of concept",
    "Production hosted in same region for a year and a half",
    "Lack of decision led to unforeseen consequences"
  ],
  "editors_take": "Choosing a region by default sets off a chain of consequences that can lead to inefficiencies, unnecessary workarounds, and long-term technical debt, making some early decisions effectively one-way streets.",
  "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."
}