JiwaAI
Blog
โ†All posts
architecture
resilience
engineering

Building AI Pipelines That Never Fully Fail

Jiwa AI Teamยท

Six Services, Infinite Failure Modes

Our content pipeline chains together web scraping, brand analysis, theme extraction, influencer matching, calendar generation, caption writing, image generation, background removal, compositing, and quality scoring. Each step calls an external service โ€” AI models, image processors, storage APIs. In a perfect world, they all succeed. In the real world, any of them can fail at any time for reasons entirely outside our control.

AI model APIs timeout. Image generation services return unexpected formats. Background removal occasionally produces artifacts. Rate limits hit at inconvenient moments. When you're building a demo for a potential client, "the AI was down" is not an acceptable answer.

Reliability vs. Resilience

The traditional engineering response to failure is reliability: retries, circuit breakers, redundant providers, and enough infrastructure to push your uptime to 99.99%. We considered this path and rejected it for a simple reason โ€” it optimizes for the wrong thing.

Our users don't need a guarantee that every component succeeds. They need a guarantee that they'll get something useful. A content calendar with five great posts and one missing image is infinitely more valuable than an error page. A brand analysis without color extraction is better than no analysis at all.

This reframing led us to design for resilience instead of reliability. Every component in the pipeline can fail without killing the components that depend on it. The system produces the best output it can with whatever succeeds.

The Fallback Chain

Image generation is where this philosophy gets its hardest workout. Our preferred approach โ€” compositing real product photos onto AI-generated backgrounds โ€” involves three separate services working in sequence. If any of them fails, we don't retry and hope. We fall back to a simpler approach.

If the composite pipeline fails, we try a style-transfer approach that's less precise but more reliable. If that fails, we use standard image generation with a detailed prompt. If even that fails, we use a faster, lower-quality model. And if everything fails, the post is saved without an image โ€” ready for the user to add one manually.

Each fallback level trades quality for reliability. The composite approach produces the best results but has the most failure points. Standard generation is less accurate but almost always works. The key insight is that these aren't separate strategies โ€” they're a chain, and the system traverses it automatically.

Failing Gracefully at Every Layer

The fallback philosophy extends beyond image generation. Brand theme analysis might fail to extract colors โ€” the pipeline continues with sensible defaults. Mood board generation might timeout โ€” content is created without style preferences. Influencer matching might return no results โ€” the calendar is generated with available influencers rather than optimal ones.

Each layer wraps its work in error handling that logs the failure and passes a degraded but functional result to the next layer. No single failure cascades into a pipeline-wide crash. The onboarding endpoint always returns something โ€” even if that something is a partially complete content plan that the user can build on.

The Cost of Graceful Degradation

This approach has real trade-offs. The code is more complex because every component needs to handle both its success path and its various failure states. Testing is harder because you need to verify behavior under partial failure, not just full success or full failure.

There's also a quality communication challenge. When the system falls back to a simpler image generation approach, the user sees a lower-quality result without necessarily understanding why. We handle this by being transparent in the dashboard โ€” posts generated with fallback approaches are flagged so users know they can regenerate when the primary service is available.

Why This Matters for AI Products

Most AI product architectures are designed like traditional software โ€” either it works or it doesn't. But AI services have a different failure profile. They don't just return errors; they sometimes return results that are technically valid but qualitatively poor. A generated image might be blurry, a caption might miss the tone, a color extraction might pick the wrong palette.

Graceful degradation handles this spectrum naturally. The fallback chain isn't just for hard failures โ€” it's for soft failures too. If the composite approach produces an image where the product looks awkwardly placed, the quality scoring layer catches it and the system can fall back to a simpler approach that produces a less ambitious but more reliable result.

The Principle

If we had to distill our resilience philosophy into one sentence, it would be this: always produce something useful, and make it easy to improve later. A partial result that ships today is worth more than a perfect result that crashes. This principle has shaped not just our error handling, but our entire product philosophy โ€” get content in front of business owners quickly, then iterate based on their feedback.