Just saw the news about Playground AI being down for hours today. 😬 I'm actually using it to generate some placeholder images for a personal project's UI. This got me thinking...
If a core service you rely on for your workflow just disappears, what do you do? I'm learning Terraform, so my first thought was "I should automate having a backup." But I'm stuck on the *how*.
For example, if I'm using their API to generate images, should I have a config that can switch to another service like Leonardo or Stable Diffusion if one fails? Is that even practical for a junior? How do you handle API keys and endpoint swaps without redeploying everything?
```hcl
# Pseudo-code idea... maybe?
variable "image_gen_service" {
description = "Primary service: 'playground' or 'backup'"
default = "playground"
}
# Then choose provider config based on var?
```
Is this overkill? Or do you just keep manual accounts on two platforms? Curious what others are doing.
Your Terraform variable idea is a decent start for configuration, but you're mixing up provisioning with runtime resilience. Terraform decides what exists when you apply, it doesn't handle a service failing at 2 AM. That's a runtime problem.
If your app calls an external API, you need logic in the application code itself, not just the IaC. A common pattern is an abstraction layer - a client class or function that wraps the image generation calls. Inside that, you implement the retry and failover logic. You'd store the API keys in a secrets manager, not in Terraform variables, and your client would fetch them. The config for which service is primary can be a runtime environment variable, so you can flip it without a redeploy.
> Is this overkill? Or do you just keep manual accounts
For a personal project? Probably overkill. The manual account backup is fine. The engineering time to build a proper failover system for a placeholder image service likely outweighs the downtime risk. For a business-critical payment service? Different story. You'd also need to consider cost, output consistency between providers, and whether your system can even detect the failure correctly - timeouts are trickier than HTTP 500 errors.
P99 or bust.
Your Terraform variable approach is actually a good way to manage *which* services are deployed, like having standby resources. But user508 is right - failover at runtime is a different beast.
For something like an image API, I'd bake the failover into your client code with a simple priority list and circuit breaker. Keep it simple: try primary, if it fails (timeout or 5xx), immediately try the backup. Your secrets come from environment variables or a vault, and the endpoint list can be a config string.
Is it overkill for a personal project? Maybe, but building that pattern is a fantastic learning exercise. It's how you graduate from "it works" to "it's resilient." Start with a single backup and manual switch, then automate the detection later.