Frequently Asked Question
Why does it take 24 hours
Why changes don’t appear instantly in a clustered service
When a service is run on several servers (a cluster), each server has its own copy of the data or configuration. To keep them in sync the change has to be sent to every node and each node must apply it. This takes a little time because:
| Reason | What it means for you |
|---|---|
| Network travel | The update has to travel over the network to each server – a few milliseconds to seconds per hop. |
| Queueing | Servers often place changes in a queue so they don’t overload the system, or interrupt jobs in progress. |
| Write‑ahead logs / snapshots | For safety the change is first written to a log, then applied to the real data store, which adds a short delay. |
| Consistency model | Some clusters prefer “eventual consistency” – they guarantee the change will arrive, but not that it will be visible instantly. |
Result: Whilst the configuration change was processed immediately, each node in a cluster will take time to receive, and process that change. This can be a few minutes, a few hours or a day.
Why DNS changes can take up to 24 hours to appear everywhere
The Domain Name System (DNS) works like a worldwide phone‑book that is cached at many levels:
- Your own computer – stores the address it last looked up (TTL = time‑to‑live).
- Your ISP’s resolver – keeps a copy for the TTL you set.
- Intermediate resolvers – other DNS servers that also cache the record.
When you change a DNS record, the new information is only sent to the authoritative server. All the cached copies elsewhere will keep serving the old value until their TTL expires.
- TTL is set by the domain owner (common values: 300 s, 3600 s, 86400 s).
- If the TTL is 24 hours (86 400 s), any resolver that cached the old entry could keep it for that long.
So even though the change is live on the authoritative server, other places may still show the previous record until their cache “times out”.
Summary
In short, replication across clusters and DNS propagation both rely on data being copied and cached in several places. The inherent travel time, queuing, and cache‑expiry periods mean you’ll usually see a delay and this is normal.
