• Exposes HTTP APIs (and optionally WebSocket) to browsers and the admin app.
• Authenticates users (e.g. JWT) and enforces roles (user vs admin).
• Owns business rules: subscriptions, market data aggregation, saving predictions, schedulers.
• Reads/writes PostgreSQL (or MySQL) and uses Redis for cache, sessions, or queues.
• Calls AI-PREDICT over an internal HTTP URL when a forecast is needed; maps the JSON response into your DB models before responding to clients.

Why it sits in the middle: browsers and admin apps never need AI service URLs or model secrets only BACKEND does.

• Renders the customer product (markets, charts, predictions, portfolio, etc.).
• Sends REST requests to BACKEND (base URL + /api/...).
• Uses WebSocket only to BACKEND for live ticks, notifications, or streaming updates if you expose them there.
• Does not call AI-PREDICT directly.

• Same pattern as FRONTEND, but for admins: users, analytics, logs, monitoring.
• Calls BACKEND admin endpoints (still REST; same origin pattern: only BACKEND).
• Uses the same auth mechanism in principle (e.g. admin JWT or role claim), stricter routes on BACKEND side.

• Exposes a small FastAPI surface (e.g. /predict, /predicts) that accepts symbol, interval, horizon, etc.
• Loads ML/DL models, runs inference, returns numbers + confidence (and any extra fields you define).
• Expects callers to be trusted (BACKEND on a private network), not the public internet.

  FRONTEND ──────► BACKEND ◄────── DASHBOARD
                     │
                     ├──► PostgreSQL / MySQL
                     ├──► Redis
                     └──► AI-PREDICT   (server-to-server only)