Every content team eventually faces the same wall: you've got six platforms to publish on, a dozen data sources feeding in, and some AI pipeline generating drafts — but none of it talks to each other without duct tape and cron jobs.
What you need isn't more tools. You need an orchestration layer.
Over the past few months, I've been designing a system that ingests content from multiple sources, processes it through AI models, and distributes it across platforms — all in real time, with fault tolerance built in from day one. Here's what the architecture looks like and the decisions that mattered.
The naive approach is a linear pipeline: fetch → process → publish. That works until one step fails and the entire chain collapses. Real-world content operations involve:
A linear pipeline can't handle this. You need an event-driven architecture.
The system uses a publish-subscribe event bus as the backbone. Every component emits and consumes events without knowing about each other.
┌──────────────┐ ┌─────────────────┐ ┌───────────────┐
│ Ingestors │────▶│ Event Bus │────▶│ Processors │
│ (RSS, API, │ │ (Redis Streams) │ │ (AI, Format, │
│ Webhook) │ │ │ │ Classify) │
└──────────────┘ └────────┬────────┘ └───────┬───────┘
│ │
▼ ▼
┌──────────────────────────────────┐
│ State Store (Postgres) │
│ + Dead Letter Queue (Redis) │
└──────────────────────────────────┘
Let's break down each layer.
Each source gets its own adapter that normalizes into a standard ContentItem
schema:
interface ContentItem {
id: string;
source: 'rss' | 'api' | 'webhook' | 'manual';
sourceUrl?: string;
rawContent: string;
metadata: Record<string, unknown>;
collectedAt: Date;
}
The adapters are stateless and emit a content.ingested
event. If an adapter crashes, the event bus doesn't care — it just won't receive events until the adapter restarts.
Key decision: We chose Redis Streams over Kafka for the event bus. The tradeoff is throughput for operational simplicity. For a media orchestration system handling hundreds (not millions) of items per hour, Redis Streams gives us consumer groups, message acknowledgments, and a dead letter mechanism without the operational overhead of a Kafka cluster.
Processors subscribe to specific event types. Each processor is a chain of middleware-style transforms:
class Pipeline {
private transforms: Transform[];
async execute(item: ContentItem): Promise<ContentItem> {
let result = item;
for (const transform of this.transforms) {
try {
result = await transform.execute(result);
} catch (error) {
await this.errorHandler.handle(error, result);
return result; // or break, depending on severity
}
}
return result;
}
}
The real trick is idempotency — if a processor crashes mid-way and gets restarted, it shouldn't reprocess the same item. Each item carries a processing version hash. If the hash matches the current pipeline version, the processor skips it.
This is where things get interesting. LLM calls are unreliable by nature — they time out, return malformed JSON, or take 30 seconds on a simple summarization.
Our approach: circuit breakers with graduated fallbacks.
class AICircuitBreaker {
private failures: number = 0;
private lastFailure: Date | null = null;
private threshold: number = 3;
private resetTimeout: number = 60000; // 1 minute
async call(prompt: string, options: AICallOptions): Promise<string> {
if (this.isOpen()) {
return this.fallbackStrategy(options); // template-based instead
}
try {
const result = await this.model.call(prompt, options);
this.failures = 0;
return result;
} catch (err) {
this.failures++;
this.lastFailure = new Date();
if (this.failures >= this.threshold) {
this.openCircuit();
}
throw err;
}
}
}
When the circuit is open, the system falls back to deterministic templates instead of failing outright. Your 2 PM newsletter still goes out — it just uses the standard intro paragraph instead of an AI-generated one.
Each platform target is a plugin. The plugin interface is dead simple:
interface PlatformPlugin {
name: string;
validate(item: FormattedContent): ValidationResult;
publish(item: FormattedContent): Promise<PublishReceipt>;
}
Plugins can be enabled/disabled at runtime via config. We can route the same content item to Twitter, Telegram, and a blog simultaneously — each handled by its own plugin with its own retry logic and rate limiting.
Three properties make this approach resilient:
This architecture handles the mechanical parts well — fetch, process, publish, retry. But what it doesn't solve on its own is the orchestration layer: deciding what to publish, when, and where, based on actual performance data.
That's where tools like Rationale come in. Rationale is an AI media orchestration engine that sits on top of architectures like this — it ingests from your existing pipelines, uses AI to optimize content strategy, and coordinates multi-channel distribution with built-in resilience patterns.
The architecture I've described is the foundation. Rationale provides the brain.
Platform architecture patterns evolve fast. The key is starting with something that survives failures gracefully — because in media operations, something will break. Build for that, and everything else is just optimization.
Check out Rationale for the orchestration layer that ties it all together.