Deployment Topologies
Questi contenuti non sono ancora disponibili nella tua lingua.
Deployment Topologies
Section titled “Deployment Topologies”Overview
Section titled “Overview”Rokks can run in managed, private, or appliance-style deployments. The public contract is consistent: users open one application URL, sign in, select scope, and work through the UI.
Components
Section titled “Components”| Layer | Responsibility |
|---|---|
| Public entry point | Presents the app and routes browser API traffic. |
| Platform services | Handle auth, documents, queries, jobs, AI, connectors, and monitoring. |
| Storage backends | Persist documents, files, metadata, and analytical tables. |
| External providers | Optional systems such as identity providers, source APIs, and notification channels. |
Data flows
Section titled “Data flows”- Browser traffic enters through the public application address.
- Authenticated requests are routed to the correct platform service.
- Worker jobs orchestrate mesh services. App Connect and Web API own source-system calls, Sentinel owns notification delivery, and persistence access stays behind the data gateways.
- Users observe progress through the app rather than connecting to individual services.
Failure modes
Section titled “Failure modes”If the public entry point is down, users cannot reach the UI. If a connector provider is down, only affected sync jobs should fail. If storage is unavailable, writes and some reads fail until the dependency recovers.
Operators should document which team owns each layer in their deployment. That ownership map is often more useful during an incident than a low-level diagram because it tells users who can restart, reconfigure, or approve a change.