Skip to content

Commit c9d8e82

Browse files
committed
[RAD] Programmable Plaforms MVP
1 parent 41dd6ed commit c9d8e82

File tree

7 files changed

+44696
-0
lines changed

7 files changed

+44696
-0
lines changed

src/assets/images/reference-architecture/programmable-platforms/programmable-platforms-1.svg

Lines changed: 7393 additions & 0 deletions
Loading

src/assets/images/reference-architecture/programmable-platforms/programmable-platforms-2.svg

Lines changed: 7421 additions & 0 deletions
Loading

src/assets/images/reference-architecture/programmable-platforms/programmable-platforms-3.svg

Lines changed: 7419 additions & 0 deletions
Loading

src/assets/images/reference-architecture/programmable-platforms/programmable-platforms-4.svg

Lines changed: 7485 additions & 0 deletions
Loading

src/assets/images/reference-architecture/programmable-platforms/programmable-platforms-5.svg

Lines changed: 7449 additions & 0 deletions
Loading

src/assets/images/reference-architecture/programmable-platforms/programmable-platforms-6.svg

Lines changed: 7409 additions & 0 deletions
Loading
Lines changed: 120 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,120 @@
1+
---
2+
title: Programmable Platforms
3+
pcx_content_type: reference-architecture-diagram
4+
products:
5+
- Workers
6+
- KV
7+
sidebar:
8+
order: 1
9+
label: Programmable Platforms
10+
updated: 2025-03-12
11+
---
12+
13+
14+
## Introduction
15+
16+
A programmable platform is a software ecosystem that enables customers to extend and customize core functionality through code. Unlike traditional SaaS offerings with fixed features, programmable platforms empower customers to build bespoke solutions within the platform's infrastructure, creating unique experiences while leveraging the platform's core capabilities.
17+
18+
Cloudflare Workers for Platforms provides the ideal infrastructure for building programmable platforms by offering secure, isolated environments where customers can safely execute custom code without compromising the integrity or performance of the underlying platform.
19+
20+
## Core Architecture Components
21+
22+
The Workers for Platforms architecture consists of several key components that work together to provide a secure, scalable, and efficient solution for multi-tenant applications:
23+
24+
1. **Dynamic Dispatch Worker**: The entry point for client requests that routes traffic to the appropriate customer-specific worker based on request parameters.
25+
26+
2. **Dispatch Namespace**: A logical grouping of customer-specific workers that isolates resources and execution environments.
27+
28+
3. **User Workers**: Customer-specific workers that process isolated workloads within their own secure execution context.
29+
30+
4. **Storage & Data Resources**: Various data storage options (D1, KV, R2, Durable Objects) that can be isolated per customer.
31+
32+
5. **Observability Tools**: Logging and metrics collection services to monitor platform performance and troubleshoot issues.
33+
34+
## Main Request Flow
35+
36+
![Figure 2: Workers for Platforms: Invocation & Metadata](~/assets/images/reference-architecture/programmable-platforms/programmable-platforms-1.svg "Figure 2: Workers for Platforms: Invocation & Metadata")
37+
38+
39+
1. **Client Request**: A request is sent from a client application to the platform's Dynamic Dispatch Worker.
40+
41+
2. **Tenant Identification & Routing**: The Dynamic Dispatch Worker identifies the appropriate customer environment using `env.namespace.get(customer-id)` and routes the request to the corresponding User Worker within the Dispatch Namespace.
42+
43+
3. **Isolated Execution**: Each customer's workload runs in an isolated User Worker with its own resources and security boundaries.
44+
45+
## Invocation & Metadata Flow
46+
47+
![Figure 2: Workers for Platforms: Main Flow](~/assets/images/reference-architecture/programmable-platforms/programmable-platforms-2.svg "Figure 2: Workers for Platforms: Main Flow")
48+
49+
50+
51+
1. **Request Routing**: Client requests are directed based on hostname or path patterns:
52+
- Custom hostnames for specific customers
53+
- Routing within a shared domain (hostname or path-based)
54+
55+
2. **Metadata Lookup**: The Dynamic Dispatch Worker may interact with KV storage to retrieve customer-specific configuration data.
56+
57+
3. **Worker Invocation**: Based on the retrieved metadata, requests are routed to the appropriate User Worker in the Dispatch Namespace.
58+
59+
## Egress Control Pattern
60+
61+
![Figure 3: Workers for Platforms: Egress Control](~/assets/images/reference-architecture/programmable-platforms/programmable-platforms-3.svg "Figure 3: Workers for Platforms: Egress Control")
62+
63+
64+
1. **Internal Routing**: The Dynamic Dispatch Worker routes requests to the appropriate User Worker within the Dispatch Namespace.
65+
66+
2. **Controlled External Access**: User Workers can make `fetch()` calls to external services through a controlled Outbound Worker.
67+
68+
3. **External Service Integration**: The Outbound Worker provides a standardized interface for communicating with external services, allowing for centralized policy enforcement, rate limiting, and audit logging.
69+
70+
## Metrics & Logging Architecture
71+
72+
![Figure 4: Workers for Platforms: Metrics & Logging](~/assets/images/reference-architecture/programmable-platforms/programmable-platforms-4.svg "Figure 4: Workers for Platforms: Metrics & Logging")
73+
74+
75+
1. **Comprehensive Logging**: All Workers in the request flow can send logs to Tail Worker and Logpush services.
76+
77+
2. **Metrics Collection**: Performance and usage metrics are captured through Analytics Engine and exposed via GraphQL.
78+
79+
3. **Third-party Integration**: Logs and metrics can be exported to various external monitoring and analytics platforms like Datadog, Splunk, Grafana, and others.
80+
81+
## Resource Isolation Model
82+
83+
![Figure 5: Workers for Platforms: Resources](~/assets/images/reference-architecture/programmable-platforms/programmable-platforms-5.svg "Figure 5: Workers for Platforms: Resources")
84+
85+
1. **Client Request**: Requests are routed through the Dynamic Dispatch Worker.
86+
87+
2. **Customer Identification**: The Dynamic Dispatch Worker identifies the appropriate customer environment.
88+
89+
3. **Resource Access**: Each User Worker has access only to its customer-specific resources:
90+
- D1 for relational database storage
91+
- Durable Objects for strongly consistent data
92+
- KV for high-read, eventually consistent key-value storage
93+
- R2 for object storage
94+
95+
## Deployment & Management Flow
96+
97+
![Figure 6: Workers for Platforms: Deployment & Management Flow](~/assets/images/reference-architecture/programmable-platforms/programmable-platforms-6.svg "Figure 6: Workers for Platforms: Deployment & Management Flow")
98+
99+
100+
1. **Management Interface**: End users interact with the platform through GUI, API, or CLI interfaces.
101+
102+
2. **Platform Processing**: The SaaS provider processes these interactions to:
103+
- Transform and bundle code
104+
- Perform security checks
105+
- Apply configuration
106+
107+
3. **API Deployment**: The processed workloads are deployed to the Dispatch Namespace via the Cloudflare REST API.
108+
109+
110+
111+
112+
## Conclusion
113+
114+
Cloudflare Workers for Platforms provides a robust foundation for building multi-tenant SaaS applications with strong isolation, global distribution, and scalable performance. By leveraging this architecture, platform providers can focus on delivering value to their customers while Cloudflare handles the underlying infrastructure complexity.
115+
116+
## Related resources
117+
118+
- [Workers for Platforms: Get started](cloudflare-for-platforms/workers-for-platforms/get-started/)
119+
- [Workers for Platforms: Outbound Workers](/cloudflare-for-platforms/workers-for-platforms/configuration/outbound-workers/)
120+
- [Workers for Platforms: Observability](/cloudflare-for-platforms/workers-for-platforms/configuration/observability/)

0 commit comments

Comments
 (0)