Back to Home

Hybrid Architecture

Powerful but complex—justify it carefully

⚠️ Complexity Warning

Hybrid architecture is not "the most real" or "the best." It's the most complicated. Only use it when the benefits clearly outweigh the duplication and security overhead.

What is it?

Hybrid architecture runs AI both client-side and server-side. Client-side AI provides immediate responsiveness and rich interactions. Server-side AI handles secrets, heavy computation, and privileged operations.

This gives you maximum flexibility, but you pay a tax: duplicated logic, complex authentication, harder debugging, and multiple threat models. You're essentially maintaining two AI systems that need to stay in sync.

💡 Key Insight

"Not 'the most real'—the most complicated. Only use when benefits clearly outweigh duplication and security overhead. The complexity tax is real and compounds over time."

Tradeoffs

Advantages

  • Maximum flexibility - use the right AI for the right task
  • Best of both worlds - responsive + secure
  • Secure + interactive - client for UX, server for secrets
  • Optimized performance - offload heavy work to server

Tradeoffs

  • Duplicated logic - maintain AI prompts in two places
  • Complex auth - who can do what where?
  • Harder debugging - issues span client and server
  • Multiple threat models - secure both surfaces
  • Easy to drift - client and server logic diverge

Technical Deep Dive

Architecture

Hybrid architecture splits AI responsibilities between client and server based on requirements: client for immediate feedback, server for security and heavy lifting.

  • •Client AI: Quick responses, user-provided keys, draft mode
  • •Server AI: Sensitive operations, controlled keys, final processing
  • •Auth Layer: Complex permissions system
  • •Sync: Keep client and server state aligned

Client vs Server: Decision Framework

Run on Client When:

  • • Need immediate, sub-second responsiveness
  • • Using multimodal browser inputs (voice, canvas)
  • • Draft/preview mode (non-committal)
  • • User is OK providing their own API key

Run on Server When:

  • • Need to protect API keys or secrets
  • • Performing privileged operations (payment, admin)
  • • Heavy computation or long-running tasks
  • • Creating durable, auditable records

Example: Ottit Feed App

Client-Side AI: Instant post suggestions as you type, real-time content moderation preview, quick semantic search
Server-Side AI: Official moderation decisions, content ranking algorithms, user embeddings and recommendations
The Sync Challenge: Client shows instant preview using user's API key. Server validates and creates final post using controlled keys. Need to keep both in sync without duplication.

⚠️ Common Pitfalls

  • •Prompt Drift: Client and server prompts diverge, creating inconsistent results
  • •Auth Confusion: Unclear what actions require server validation
  • •Double Work: Both client and server do similar tasks wastefully
  • •Testing Nightmare: Need to test all combinations of client + server states

When to Use This Pattern

  • ✓Complex apps where responsiveness AND security both matter deeply
  • ✓You've exhausted simpler patterns and have clear justification
  • ✓Team has strong experience with distributed systems
  • ✓Budget allows for higher development and maintenance costs

When NOT to Use This Pattern

  • ✗You're building an MVP or prototype (start simpler)
  • ✗Client-side or backend-driven alone would work
  • ✗Team lacks distributed systems experience
  • ✗You can't clearly articulate why you need both

Apps Using This Pattern

Ottit

Hybrid feed app with client and server AI

Visit Live Demo

Want to explore other architecture patterns?

View All Patterns