Pangkalahatang Pagtingin sa Workers Platform
Ang Cloudflare Workers ay isang FaaS na batay sa V8 Isolate, at sa Abril 2026, ang parehong code ay agad na nide-deploy sa mahigit 330 PoP sa buong lungsod. Ang cold start ay halos zero (mas mababa sa 5ms para sa maraming request), ngunit dahil sa mga limitasyon ng paggamit ng Isolate kaysa sa container startup tulad ng AWS Lambda, ang native Node.js modules at matagal na blocking I/O ay hindi talaga angkop. Sa pamamagitan ng nodejs_compat_v2 na naging GA noong ikalawang kalahati ng 2025, lubos na napabuti ang compatibility ng fs, crypto, at stream, ngunit kung sumulat ka nang hindi naiintindihan ang 'paraan ng Isolate', makikita mong mabilis na maapektuhan ng subrequest limit (1000) o CPU time limit (5 minuto sa bayad na plano).
Ang Workers ay talagang nagpapakita ng halaga kapag pinagsama sa Durable Objects para sa may-stateful na lohika. Ang Durable Object (DO) ay isang 'actor na may globally unique ID, single-threaded, at may malakas na consistency', at ang mga request sa parehong DO ay palaging serialized. Ang modelong ito ay dinisenyo bilang 'kapalit ng mutex sa edge', at ang mga 'per-user rate limiting', 'per-meeting-room signaling', at 'per-transaction-ID inventory allocation' na dati ay isinasagawa gamit ang Redis o Postgres advisory lock ay maaari na ngayong makumpleto nang lokal nang walang RTT.
Transaksyon na Modelo ng Durable Objects
Ang persistent store ng DO ay nagbibigay ng storage API na batay sa SQLite sa loob nito. Mula nang buksan ang SQLite-backed DO sa lahat ng plano noong 2025, hanggang 10GB ng relational data ang maaaring iimbak sa bawat DO, at ang maraming put/delete ay maaaring isagawa nang atomically sa loob ng transaction() callback. Ang mahalaga ay ang DO ay naglalaman ng 'input gate' at 'output gate'. Hinaharangan ng input gate ang mga bagong request habang naghihintay para sa storage write sa panahon ng request processing, at pinapanatili ng output gate ang fetch response hanggang ang storage write ay naging persistent. Sa pamamagitan ng double gate na ito, kahit na magsulat nang malaya ng async/await sa application code, ang consistency ay hindi masisira.
```typescript export class InventoryDO { state: DurableObjectState; constructor(state: DurableObjectState) { this.state = state; } async fetch(req: Request) { const { sku, qty } = await req.json<{ sku: string; qty: number }>(); return await this.state.storage.transaction(async (tx) => { const current = (await tx.get<number>(sku)) ?? 0; if (current < qty) return new Response("oos", { status: 409 }); await tx.put(sku, current - qty); return new Response(JSON.stringify({ remain: current - qty })); }); } } ```
Ang karaniwang maling paggamit kapag ginamit ang DO bilang actor ay ang disenyo ng 'pag-process ng lahat ng tenant sa 1 DO'. Kapag naging hotspot ang DO, ang PoP ay naayos, na nagpapataw ng mataas na RTT sa mga gumagamit na malayo sa heograpiya. Ang tamang sagot ay pag-shard sa pamamagitan ng pagsasama ng 'tenant ID + resource ID' gamit ang idFromName(), at ang pag-aayos ng pag-ilagay nang may geographical locality ang mga write. Ang mga read ay maaaring ibalik sa O(1) mula sa asynchronous replica gamit ang replica DO (2025 GA).
Paggamit ng Workers KV, Hyperdrive, at D1
Ang tatlong data layer ay may malinaw na naiibang layunin. Ang Workers KV ay isang read-optimized store na may eventual consistency, angkop para sa mga setting at metadata na maaaring tanggap ang pagpapalaganap sa loob ng 60 segundo. Ang pagpapalaganap ng PUT ay ilang segundo hanggang 60 segundo, at ang mga read ay ibinabalik sa 1ms mula sa lokal na cache ng PoP. Ang Hyperdrive ay isang connection pooler para sa panlabas na Postgres/MySQL, na nagre-reuse ng TCP connections sa origin habang kino-cache ang mga resulta ng query sa PoP. Ito ang pinakamakatotohanang unang hakbang para sa mga organisasyong may kasalukuyang RDB assets na gumagawa ng edge migration. Ang D1 ay ang sariling SQLite-based RDB ng Cloudflare, at noong 2025, ang read replica ay naging GA, na nagpapahintulot ng PostgreSQL-style topology kung saan ang mga write ay sa primary at mga read ay sa pinakamalapit na replica.
Ang pamantayan ng pagpili ay tinukoy sa 'dalas ng write' at 'kinakailangan ng consistency'. Ang karaniwan sa practice ay: DO para sa mahigit 1000 writes bawat segundo na maaaring ihiwalay sa bawat tenant, D1 para sa maliit na global writes + geographically distributed reads, Hyperdrive kung mayroon nang panlabas na DB, at KV para sa TTL-based na pamamahagi ng configuration. Ang R2 (S3-compatible object storage) ay patayo sa mga ito, at ginagamit para sa video distribution, backup, at data lake gamit ang katangian ng libreng egress.
Workers AI at Inference Routing
Mula nang maging GA ang Workers AI noong 2024, maaari na itong tumawag ng mga pangunahing OSS model tulad ng Llama 3.3 70B, Mistral Large 2, GPT-OSS-120B, at Qwen 3 series nang pay-as-you-go. Sa 2026, ang BYOK ay nagbibigay-daan sa routing ng OpenAI/Anthropic/Google sa pamamagitan ng parehong API (AI Gateway), at ang caching ng response, pag-uulit, at rate limiting ay maaaring pinamamahalaan nang naka-isa sa panig ng Workers, na ito ang kalamangan. Dahil ang mga log ng AI Gateway ay dumadaan sa Analytics Engine, ang gastos ng token bawat prompt ay maaaring i-query sa SQL.
Ang karaniwan para sa latency optimization ay 'lokal na inference ng Workers AI para sa maliliit na judgment, panlabas na LLM para sa kumplikadong inference'. Halimbawa, ang bot detection, NSFW classification, at multilingual detection ay tapos na gamit ang Llama Guard/Llama-3 8B ng Workers AI, at ang two-stage routing na nagtataguyod lamang sa Claude o GPT kapag ang resulta ay 'hindi tiyak' ay nagpapababa ng gastos ng 70%, at maraming kaso ang nakita ng aming kumpanya.
Rust + WASM Binding para sa Hot Path Optimization
- ms sa TypeScript, 0.8ms sa Rust + WASM. Ang pagkakaibang ito ay nakakaapekto sa CPU time budget sa 100,000 requests bawat segundo. Ang workers-rs (Rust crate) ay maaaring i-compile sa Workers runtime gamit ang #[event(fetch)] macro, at maaaring ma-access ang JS APIs (fetch/crypto/R2) sa pamamagitan ng wasm-bindgen. Ang pagsusulat muli ng mabigat na JSON parsing ng API gateway, HMAC verification, JWT verification, at image resizing sa Rust ay may malaking epekto sa pagbabago ng gastos.
```rust use worker::*; #[event(fetch)] async fn main(req: Request, env: Env, _ctx: Context) -> Result<Response> { let body: serde_json::Value = req.json().await?; let signature = req.headers().get("x-signature")?.unwrap_or_default(); if !verify_hmac(&body, &signature, &env.secret("HMAC_KEY")?.to_string()) { return Response::error("invalid signature", 401); } Response::ok("ok") } ```
Bilang mga pag-iingat, ang laki ng WASM module ay dapat panatilihing hanggang 10MB, at ang kombinasyon ng wasm-opt -Oz at wee_alloc ay maaaring makapagbawas ng epektibong laki ng kalahati. Ang startup cost ay halos mapapabayaan dahil sa Isolate reuse, ngunit ang unang compilation ay tumatagal ng 20-50ms, kaya sa mga PoP na may napakababang traffic, may nangyayaring reverse phenomenon kung saan ang TypeScript ay mas mabilis. Kinakailangan ang benchmarking sa production PoP.
Mga Pattern ng Pagtatayo ng Global State Machine
Ang kombinasyon ng WebSocket Hibernation + Durable Objects ay naging standard para sa real-time collaborative editing, signaling para sa live streaming, at IoT device orchestration. Sa pamamagitan ng Hibernation API, ang mga WebSocket connection ay maaaring manatiling bukas habang inilalabas ang memorya, at ang bayad para sa DO ay 'aktibong oras' lamang. Ang istruktura ng gastos na mananatili sa ilang libu-libong dolyar bawat buwan kahit na pinapanatili ang 1 milyong koneksyon ay nagbibigay ng motibasyon para muling gawin sa sarili ang mga serbisyong tulad ng Ably o Pusher.
Ang pangunahing punto sa disenyo ay ang pagtrato sa DO bilang 'isang node ng state machine'. Ang mga state transition ay ini-update nang atomic ang state version gamit ang CAS sa loob ng storage.transaction, at ang mga panlabas na event ay pinapalabas sa pamamagitan ng Queues. Ang mga compensating transaction sa oras ng pagkabigo ay maaaring isagawa nang may pagkaantala gamit ang alarm() API. Sa ganitong paraan, ang saga pattern na 'nagsisimula sa edge at nagtatapos sa edge' ay maaaring organisahin nang may mababang latency. Ang arkitektura na hindi bumabalik sa origin ay ang pangunahing larangan ng 2026 distributed system design.