“Services are ephemeral” means:
Services can be created, destroyed, restarted, or moved at any time — often automatically and unpredictably.
In Simple Terms
- Ephemeral = short-lived, temporary, dynamic.
- A service might:
- Restart due to a crash.
- Be rescheduled to a different machine (e.g., by Kubernetes).
- Be killed and replaced during scaling or deployment.
Real-World Context
In traditional systems:
- Services ran on fixed servers with static IPs.
- You could hardcode locations.
In modern, cloud-native systems:
- Services run in containers (e.g., Docker).
- Orchestrators like Kubernetes or ECS spin up and kill containers on demand.
- You can’t rely on IP addresses or hostnames to remain the same.
Why Does This Matter?
If services are ephemeral:
- You must use Service Discovery to locate them.
- Logs and state should go to external systems (e.g., cloud storage, databases).
- Services should be stateless so they can be replaced without loss.
Implications for System Design
| Design Decision | Because Services Are Ephemeral… |
|---|---|
| No hardcoded IPs | Use DNS or service registry. |
| Externalized state | Store data in DBs, not in memory. |
| Logging to remote | Logs should go to centralized storage (e.g., ELK). |
| Health checks | To kill and replace failing instances. |
| Autoscaling | Services spin up/down based on load. |
Example
You deploy a payment-service on Kubernetes:
- It gets a random pod name like
payment-7648d9c7f8-abcde. - Tomorrow, that pod dies. A new one spins up:
payment-7648d9c7f8-fghij. - Same service, but different identity (IP/hostname). Your system must not break when this happens.
Bottom Line
“Ephemeral services force you to design for resilience, scalability, and dynamism. You can’t assume anything is permanent.”