center

Quote

Hello, hello! It has been a while since I shared a hands-on, DIY technical project. Lately, I’ve been heavily focused on W’xOps IDP, which is currently in a maintain-and-refactor phase as me prepare for its first open-source (OSS) release.

While that’s brewing, I decided to take a short break to build something fun, slightly complex, and practical, just to keep my hands-on skills sharp!

A few days ago, I received a request to build a Task Management and KPI Tracking Bot. This led me down the path of Serverless Architecture, a fantastic approach for optimizing costs, designing lightweight systems, and keeping things fun to build.

Without further ado, let’s dive right into this week’s topic!

Serverless Architecture and The story surround them

TL;DR

The first part of the article focuses on delving deeper into Serverless Architecture and System Architecture Design. Additionally, I discuss AI/ML and Cloud Native Solutions (Knative) in conjunction with Serverless.

Therefore, if you prefer not to explore Serverless and would rather jump straight to the showcase solution, you can skip Part 1 and proceed directly to Part 2 of this session. Thank you!

As mentioned earlier, I was tasked with designing an automated workflow to integrate daily messaging platforms, such as Zalo (widely used in Vietnam) and Telegram - for workload tracking and KPI management. To build an efficient end-to-end solution, I combined several architectural patterns: Chatbots, Serverless Compute, and SQLite Databases.

This combination offers key strategic advantages:

Cost Optimization: Leverages generous free tiers and low-cost pay-as-you-go pricing models.
Streamlined Deployment: Supported by modern developer frameworks that simplify development, testing, and deployment.
Zero Server Management: Eliminates the operational overhead of provisioning and maintaining infrastructure (even though servers still exist behind the scenes).
Elastic Scalability: Cloud vendors handle auto-scaling out of the box, allowing serverless functions to scale seamlessly from zero to peak demand.

center

Why Serverless

As usual, I will try to explore what technologies hand-on and which options are available on the marketplace for free and commercial. You can explore more about these articles blow about Serverless and the decision making when choose Serverless.

Abstract

Serverless is a cloud-native development model that allows developers to build and run applications without having to manage servers.

This architecture is designed to free developers from server management, allowing them to focus strictly on building applications faster. As noted earlier, your code still runs on physical or virtual servers; however, the cloud provider abstracts and manages the underlying infrastructure, offering a unified interface to interact with your services.

This architecture fits my requirements because Serverless Architecture typically pairs with Event-Driven Architecture, a modern pattern where events trigger and orchestrate communication between decoupled components. An event is essentially a message emitted when a state change occurs. This design allows individual components to scale, update, and operate independently, which is why individual execution units are termed “Functions” across major public clouds (e.g., Azure Functions, AWS Lambda).

Info

Functions are single-purpose execution blocks well-suited for serverless execution. They request compute resources (CPU and memory) on demand only when executed, maximizing efficiency.

Serverless allows functions to scale efficiently and effortlessly. In traditional architecture (such as dedicated Virtual Private Servers or compute instances), you are constrained by pre-allocated resources that you must manually manage and size. In contrast, serverless functions provide elastic, virtually infinite scalability. A single serverless function can seamlessly handle one or one million requests without any code modifications.

Given these core capabilities, Serverless Architecture is well-suited for several key use cases:

Stateless Application Development: Ideal for asynchronous, stateless workloads that do not retain client session state between calls (e.g., Chatbots, Task Schedulers, and IoT ingestion).
Batch Processing: Periodically handles high-volume, repetitive data processing jobs like automated backups, log filtering, and data transformations.
Real-Time Data Analytics: Integrates with real-time streaming pipelines to process telemetry and event data immediately for rapid customer responsiveness.
Machine Learning Inference: Offers cost-effective serving for model endpoints with variable traffic patterns, provided cold-start latencies remain acceptable.

While Function-as-a-Service (FaaS) is the most widely recognized serverless model, the paradigm spans several architectural implementations:

Function-as-a-Service (FaaS): FaaS runs event-driven logic inside ephemeral containers without persistent server management, executing strictly upon invocation.
Backend-as-a-Service (BaaS): BaaS provides fully managed cloud backend services covering authentication, databases, push notifications, and object storage, commonly consumed by mobile and web clients.
Serverless Databases: Managed serverless database options that auto-scale capacity and storage transparently based on query load (e.g., AWS Aurora Serverless, AWS Timestream, AWS DynamoDB).
Serverless Containers: Combine the packaging flexibility of OCI/Docker containers with serverless auto-scaling and zero-node management (e.g., AWS Fargate, Azure Container Apps).
Serverless Edge Computing: Executes logic directly on geographically distributed edge nodes close to end-users, delivering ultra-low latency alongside pay-as-you-go scaling (e.g., Cloudflare Workers, AWS Lambda@Edge, Vercel Edge Functions, Apache OpenWhisk).

Quote

Serverless is a compelling and flexible architecture that leverages abstract compute models to convert application deployments into fully managed, self-scaling micro-units. The optimal choice among these serverless patterns depends entirely on your specific workload demands, operational constraints, and business requirements.

The Advantage and Trade-off

Serverless architecture is tailored for a wide array of use cases and has become a popular design pattern when architecting new projects from scratch. However, like any technology, it is a double-edged sword: while offering significant advantages, the trade-offs and operational costs must be carefully evaluated.

Advantages

Cost Efficiency & Pay-as-You-Go: You pay strictly for execution time and consumed resources rather than idle compute capacity.
Seamless Architectural Integration: Easily orchestrate functions alongside Webhooks, API Gateways, CDNs, databases, and event brokers without infrastructure bottlenecks.
Rapid Deployment & Iteration: Extensive tooling and frameworks streamline shipping serverless applications, enabling rapid iteration and automated deployment pipelines.
Built-in Infrastructure Security: Cloud providers manage OS patching, underlying runtime security, and hardware isolation, mitigating server misconfiguration risks.
Elastic Auto-Scaling: Functions and managed backends automatically scale up or down dynamically in response to incoming request spikes or drops.
Zero Infrastructure Management: Eliminates the operational overhead of provisioning, patching, and maintaining servers, freeing engineering teams to focus purely on business logic.

Disadvantages & Challenges

Cold Start Latency: Unlike persistent servers that run continuously, serverless functions experience initial invocation latency when spinning up new ephemeral environments on demand.
Architectural & Operational Complexity: Splitting application logic into dozens of isolated functions increases system complexity, requiring dedicated workflow orchestration tools (e.g., AWS Step Functions) as pipelines expand.
Resource & Execution Limits: Cloud vendors enforce strict maximum thresholds on memory allocation, execution timeouts, and concurrency limits, making long-running or resource-intensive tasks difficult to execute natively.
Debugging & Observability Overhead: Distributed, asynchronous workflows make end-to-end distributed tracing, log aggregation, and local debugging challenging, often increasing third-party observability costs.

Explore more about challanges and trade-offs when work with Serverless

Serverless in System Architecture Design

Because the flexibility of Serverless for designing the architecture pattern, therefore, you will have more than one opproach to pursuit when you think about Serverless in your system, including

Request-Response / API Proxy Pattern

Abstract

A client sends a synchronous HTTP request to an API Gateway, which routes it directly to a serverless function. The function processes business logic, queries a database, and returns a response immediately.

Preferred Use Cases: Web/mobile backends, REST/GraphQL APIs, user authentication, interactive search, third-party webhook handlers.

Candidate Tools

Cloud and Commericial
- Compute: AWS Lambda, Azure Functions, Google Cloud Run / Cloud Functions.
- API Management: AWS API Gateway, Azure API Management, GCP API Gateway.
- Data: Amazon DynamoDB, Azure Cosmos DB, Cloud Firestore.
Open Source
- Compute: KNative Serving, OpenFaaS
- API Management: Envoy Proxy, Kong Gateway

Fan-Out / Pub-Sub (Event-Driven) Pattern

Abstract

An event producer publishes a single state change to a message broker, which automatically broadcasts the event to multiple independent consumer functions running in parallel.

Prefered Use Cases: Multi-channel notifications (Email, Push, SMS), file upload processing (generating thumbnails, video transcoding, OCR text extraction), audit logging.

Candidate Tools

Cloud and Commericial
- Event Routers: AWS EventBridge / SNS, Azure Event Grid / Service Bus, GCP Pub/Sub.
- Storage Triggers: AWS S3 Streams / DynamoDB Streams, Azure Blob Storage triggers.
Open Source: Apache Kafka, Apache Pulsar, Knative Eventing, Dapr Pub/Sub, RabbitMQ

Queue-Based Buffer

Abstract

Incoming requests drop into a durable queue. Serverless functions consume messages in controlled batches or with concurrency limits to smooth out traffic spikes.

Preferred Use Cases: Flash sale order processing, high-throughput IoT telemetry ingestion, batch database writes to legacy systems.

Candidate Tools

Cloud and Commericial
- Queues: AWS SQS, Azure Queue Storage / Service Bus Queues, GCP Cloud Tasks.
- Throttled Compute: AWS Lambda (with reserved concurrency limits), Azure Functions, GCP Cloud Functions.
Open Source: RabbitMQ, Redis Streams, Apache ActiveMQ.

Saga / Step Orchestration Pattern

Abstract

A centralized state engine steps through a multi-service business transaction sequentially, handling state tracking, retries, and automated compensation (rollbacks) if a step fails.

Preferred Use Cases: E-commerce order fulfillment (inventory lock $\to$ charge payment $\to$ create shipping label), banking transfers, multi-stage data ETL.

Candidate Tools:

Cloud and Commericial
- Orchestrators: AWS Step Functions, Azure Durable Functions / Logic Apps, GCP Cloud Workflows.
Open Source: Temporal.io, Dapr Workflows, Zeebe (Camunda), Netflix Conductor.

Choreography Pattern

Abstract

Autonomous serverless functions publish and subscribe to a central event bus, reacting independently to upstream domain events without a central controller.

Preferred Use Cases: High-throughput microservice ecosystems, independent product feature teams, short event chains (2–4 steps) requiring sub-second execution.

Candidate Tools:

Cloud and Commericial: AWS EventBridge + Lambda, Azure Event Grid + Functions, GCP Eventarc + Cloud Run.
Open Source: Apache Kafka, NATS JetStream, Knative Eventing.

Saga Orchestration vs Choreography

Both of them quite look great pattern to setup the Serverless Architecture and here what you can delve deeper to see them different for what and which use-case prefer to use them.

Dimension	Orchestration (State Machine)	Choreography (Event-Driven)
Control & State	Centralized in a workflow engine (e.g., AWS Step Functions, Temporal).	Decentralized across local service databases and event topics.
Service Coupling	Medium-High: The orchestrator must know every service’s API contract.	Low: Services only need to know about incoming and outgoing event schemas.
Failure Handling	Native: Automated retries, timeouts, and structured error catching/rollbacks.	Complex: Services must listen for failure events (e.g., `PaymentFailed`) to trigger local rollbacks.
Visibility & Tracing	High: Single dashboard visualizes status, execution path, and failing nodes.	Distributed: Requires correlation IDs and tracing tools (e.g., OpenTelemetry, AWS X-Ray).
Performance & Latency	Higher Latency: State persistence and orchestrator network hops add overhead.	Lower Latency: Direct event handoff without intermediary state execution steps.

Explore more about the different between SAGA Pattern with Orchestration and Choreography

CQRS (Command Query Responsibility Segregation) Pattern

Abstract

Separates write operations (Commands) from read operations (Queries). Writes update a transactional database, emitting stream events to populate read-optimized indexes or caches asynchronously.

Preferred Use Cases: Systems with high read-to-write ratios, e-commerce catalog search with complex filtering, real-time analytics dashboards, e.g: E-commerce product search with complex filters, social media activity feeds, real-time analytics dashboards.

Candidate Tools:

Cloud and Commericial: AWS DynamoDB Streams + Kinesis + OpenSearch, Azure Cosmos DB Change Feed + Cognitive Search, GCP Firestore + Bigtable.
Open Source: Debezium (CDC) + Apache Kafka + OpenSearch / Elasticsearch.

Explore more about this pattern with

Strangler Fig Pattern

Abstract

An API Gateway or Load Balancer intercepts incoming monolith traffic and selectively redirects individual route paths to new serverless microservices until the legacy backend is fully retired.

Preferred Use Cases: Migrating legacy enterprise monoliths to cloud-native microservices without a high-risk “big bang” rewrite.

Candidate Tools:

Cloud and Commericial: AWS API Gateway / Application Load Balancer, Azure API Management, GCP Apigee.
Open Source: Traefik, Kong Gateway, NGINX, Envoy Proxy.

Explore more about pattern with Serverless

Conclusion

Pattern	Coupling	Execution Mode	Latency	Complexity	Primary Strength
Request-Response	Tight	Synchronous	Low	Low	Immediate, interactive data processing
Fan-Out / Pub-Sub	Loose	Asynchronous	Low-Medium	Medium	Parallel notification across multiple services
Queue-Based Buffer	Loose	Asynchronous	Medium	Low-Medium	Leveling traffic spikes to protect downstream stores
Saga Orchestration	Loose	Async / Stateful	Medium	High	Centralized control and automated rollbacks
Choreography	Very Loose	Asynchronous	Low	Medium-High	Autonomous service execution with low latency
CQRS	Decoupled	Eventual Sync	Low (Reads)	High	Fast search/reads isolated from transactional writes
Strangler Fig	Decoupled	Sync / Async Proxy	Variable	Medium	Risk-free, incremental legacy monolith modernization

If you want to find pattern, solutions and case-studies around Serverless Architecture and Computing, check out these links below

AI and LLM with Serverless Architecture 2026

With Serverless Architecture, AI and LLM have more space and tools to being optimization. Because the price of GPU are truly expensive and Serverless can be the solution for saving lots money and keep your AI/ML model still be available for inference and workflow agentic with these pattern above

Queue-Based Buffer + Event-Driven Scaling (The GPU Optimizer)

Problem

Because the GPU are expensive and easily crash with OOM error during traffic surges for heavy AI tasks (Batch Inference, Image/Video Generation, Embeddings)

Solution: To solved problem, Incomming AI Inference prompts drop into Queue and use KEDA for monitoring the queue depth and scale GPU worker pods (vLLM or Ray) for batch inferencing and protect GPU vRAM

Use Cases: Batch LLM processing, AI image/video generation (Stable Diffusion/Flux), asynchronous audio transcription.

K8s & Cloud Candidates: KEDA, Ray Cluster, Apache Kafka, RabbitMQ, AWS SQS, GCP Cloud Tasks.

Explore more about articles use this pattern

Saga / Step Orchestration (The Agentic AI & Pipeline Engine)

Problem

Agentic workflows execute non-deterministic, multi-step LLM loops with external API tool calls. If step 4 of 5 fails or times out, standard stateless retries burn expensive tokens, corrupt global state, or leave side-effects (like partial database writes) unhandled.

Solution: Implement stateful Saga Orchestration to isolate each step with persistent checkpoints for LLM decisions, vector retrieval, or tool execution. This ensures that failures trigger rollbacks only at the exact point of failure rather than rolling back the entire workflow, while keeping the original meaning intact.

Use Cases: Multi-tool autonomous coding/research agents, enterprise document processing with human-in-the-loop approvals, complex multi-modal ETL pipelines.

K8s & Cloud Candidates:

Cloud Native (K8s): Temporal, Restate, LangGraph Server, Prefect, Inngest, CrewAI on K8s.
Commercial / Public Cloud: AWS Step Functions, Azure Durable Functions, GCP Workflows, Trigger.dev.

Explore more several articles below about SAGA Orchestration with Serverless for AI/ML

CQRS (The RAG & Knowledge Indexing Engine)

Problem

Document ingestion, chunking, and embedding generation (Write Path) are heavy, batch-oriented CPU/GPU operations that spike intermittently. Semantic retrieval (Read Path) requires sub-100ms vector similarity searches. Mixing both on a unified service leads to search latency spikes, lock contention, and VRAM/RAM starvation.

Solution: Decouple the ingestion pipeline from the search engine using Command Query Responsibility Segregation (CQRS).

Command (Write) Path: Asynchronous queues capture incoming documents. Ephemeral GPU/CPU worker pods parse, chunk, embed, and batch-upsert data into storage.
Query (Read) Path: Incoming user queries hit a lightweight, read-optimized vector database replica equipped with in-memory indexes (e.g., HNSW) and fast re-ranking sidecars, completely isolated from ingestion load.

Use Cases: Enterprise knowledge base RAG, real-time news/social media semantic indexing, multi-tenant document search platforms.

K8s & Cloud Candidates:

Write Path: Ray Data, Unstructured.io, Apache Kafka, RabbitMQ, KEDA.
Read Path: Qdrant, Milvus, Pinecone, Weaviate, PGvector (with pg_vectorize).
Managed Solutions: AWS Bedrock Knowledge Bases, GCP Vertex AI Search.

Explore more article about this topics

Streaming Request-Response (Real-Time LLM Serving)

Problem

LLM generations take seconds to minutes to complete. Standard synchronous HTTP/REST APIs buffer the response until full generation ends, triggering API Gateway timeouts (e.g., AWS 29-second limit), increasing serverless proxy VRAM/memory footprint, and delivering a sluggish user experience.

Solution: Establish an event-driven streaming transport channel (Server-Sent Events [SSE] or WebSockets) through edge proxies supporting HTTP/2 multiplexing and chunked transfer encoding. The inference backend streams generated tokens frame-by-frame directly to the client as they leave VRAM, keeping initial Time-to-First-Token (TTFT) under 200ms while maintaining lightweight connection states on the proxy layer.

Use Cases: Real-time interactive LLM chats, inline IDE code completion, streaming text-to-speech (TTS) synthesis.

K8s & Cloud Candidates:

Inference Engines: vLLM, SGLang, TensorRT-LLM, TGI.
Ingress & Gateways: Envoy Gateway, Istio, Kong, Traefik.
Serverless Edge / Cloud: Cloudflare Workers, Fastly Compute, AWS API Gateway (HTTP APIs SSE), GCP Cloud Run (Response Streaming).

Explore the article for more information about this pattern AWS - Serverless strategies for streaming LLM responses

Low-Latency Interactive Inference (Buffered Scale-to-Zero)

Problem

Interactive LLM/Chat applications require low Time-to-First-Token (TTFT). Naive scale-to-zero drops client connections or causes unbearable timeouts when spinning up empty GPU instances that must download $10 - 100 GB$ of weights.

Solution: An ingress/activator proxy buffers incoming requests while a cluster autoscaler provisions a node. The pod boots using local NVMe host-level weight caches (via P2P image/file caching or shared mount volumes like JuiceFS) to bypass container layer downloads. The request is released to the warm instance, streaming tokens back over SSE or gRPC

Use Cases: Real-time streaming LLMs, customer support voicebots, interactive coding assistants.

Candidates & Tools:

Cloud Native (K8s): KServe, Knative Serving (Activator), vLLM / SGLang, Spegel / JuiceFS.
Commercial / Public Cloud: Google Cloud Run for GPUs (L4/A100), AWS Bedrock, Modal, RunPod Serverless, Baseten.

Explore the article for more information about this pattern Blog - Scaling GPU inference to zero and back

Dynamic LoRA Hot-Swapping (Multi-Tenant Base Instance)

Problem

Provisioning dedicated GPU replicas for hundreds of tenant-specific fine-tuned models leads to massive infrastructure costs and GPU idling.

Solution: Maintain a warm “base model” instance (e.g., Llama 3 70B) in GPU VRAM. Incoming requests specify a Low-Rank Adaptation target (lora_id). The inference engine dynamically fetches and overlays small LoRA adapters (tens of megabytes) in VRAM on-the-fly per request without resetting the base model state.

Use Cases: Enterprise B2B SaaS with custom customer personas, localized language translation, domain-specific contract analysis.

Candidates & Tools:

Cloud Native (K8s): vLLM (Multi-LoRA dynamic loading), SGLang, BentoML.
Commercial / Public Cloud: Predibase, AWS Bedrock Custom Models, GCP Vertex AI Model Garden.

Explore these articles below for more information about this pattern

Conclusion

Pattern	Core Architectural Goal	Latency Profile	Primary Use Cases	Cloud Native (K8s / OSS)	Commercial / Public Cloud
Buffered Scale-to-Zero	Eliminate cold starts using ingress buffering & NVMe host-level weight caching	Low (<200ms TTFT start)	Real-time chat, voicebots, inline code completion	KServe, Knative, vLLM, Spegel, JuiceFS	GCP Cloud Run (GPUs), Modal, AWS Bedrock, Baseten
Dynamic LoRA Hot-Swapping	Serve thousands of fine-tuned models on a single base model in VRAM	Low-to-Medium (On-demand adapter fetch)	Enterprise B2B SaaS, tenant custom personas, localized translation	vLLM (Multi-LoRA), SGLang, BentoML	Predibase, AWS Bedrock, GCP Vertex AI Model Garden
Queue-Depth Async Batch	Scale GPU pods dynamically based on queue depth/backlog to prevent VRAM OOMs	Asynchronous / High Throughput	AI image/video generation (Flux), offline scoring, dataset creation	KEDA, Ray Cluster, Apache Kafka, RabbitMQ	AWS SQS + Karpenter, GCP Cloud Run Jobs, Modal, RunPod
Saga Orchestration	Provide state checkpointing and compensating rollbacks for failed agent actions	Step-based / Event-driven	Complex multi-agent execution, human-in-the-loop approvals	Temporal, LangGraph Server, Restate, Prefect	Azure Durable Functions, AWS Step Functions
CQRS for RAG	Decouple heavy embedding ingestion (Write) from sub-100ms vector lookups (Read)	Read: <100ms Write: Async batch	Enterprise knowledge base search, real-time news semantic indexing	Ray Data, Unstructured, Qdrant, Milvus, PGvector	AWS Bedrock KB, GCP Vertex AI Search, Pinecone
Streaming Request-Response	Stream tokens frame-by-frame via SSE/WebSockets to bypass 30s gateway limits	Real-time (<200ms TTFT)	Interactive LLM chat, real-time text-to-speech (TTS), inline IDE assistance	vLLM, SGLang, TensorRT-LLM, Envoy Gateway	Cloudflare Workers, GCP Cloud Run, AWS API Gateway

Explore more about the several articles shared about these pattern with real use-cases below

Bonus: Cloud Native, Edge Computing with Serverless

My interest in delving deeper into serverless computing stems from its tight coupling with the present and future of IT infrastructure. Attending KubeCon Japan 2026 exposed me to advanced use cases, such as Edge Computing (e.g: KubeEdge, K0s), that are not yet widely adopted within my local market. Explore more them via my session at For Japan and KubeCon 2026 - Recaps and Keynotes

During this servless Architecture, I just ask why not if we find out the diverse of Edge Computing, Serverless for small workload but run them in edge node, orchestration and reponse the end result, the combination called Cloud-edge Continuum, and you can explore more about them via these articles below

Following reasearch and AI Involving, I see there are severals point to combine them into one workflow with high dependencies and intelligence loop works, and these step cover by

Cloud Native Heavy Processing: The observability, ranking, training and quatization model as automatically should processed on this pipeline ⇒ Scale down model into size INT4/FP8
Low-Power Edge Execution: Lightweight runtimes (like WasmEdge or micro-containers) run compressed $1 - 7 B$ parameter models or tiny LoRA adapters directly on local NPU or GPU hardware.

Info

There are Low-Power said about micro-containers, so it refers to stripping down traditional containerization to its bare minimum binary dependencies to eliminate OS overhead on constrained edge hardware. There are 3 Technologies Powering “Micro-Containers”

Minimal OCI Containers (Distroless & Scratch Images): distroless

Embedded Container Engines & Runtimes: crun / youki start containers in sub-50ms with single-digit megabyte RAM footprints, or balenaEngine, A purpose-built IoT container engine 3.5x smaller than Docker CE, uses binary diffing (deltas) to send 10x smaller updates, and prevents storage corruption during sudden power losses.

MicroVMs and Unikernels: MicroVMs (Firecracker / Cloud Hypervisor): Strips away hardware emulation from traditional QEMU VMs. Or Unikernels (Unikraft, OSv) Compiles your AI inference code and only the exact operating system primitives it needs into a single bootable binary image, bypassing traditional Linux user-space entirely.

Dimension	WebAssembly (WasmEdge)	Micro-Containers (crun / Distroless / Balena)
Isolation Level	Process-level sandbox (WASI capability model)	OS-level kernel isolation (Linux cgroups & namespaces)
Cold-Start Time	Sub-10ms (instant invocation)	50ms – 500ms
Memory Footprint	Ultra-low (1 MB – 10 MB)	Low (15 MB – 50 MB)
C/C++ AI Library Support	Requires WASI-NN bindings or dynamic host calls	Native support for any Linux C++/CUDA/TensorRT driver
Tooling Compatibility	Emerging Wasm ecosystem (Spin, Wasmtime)	Standard OCI/Docker registries, Helm, and K8s manifests

Edge-to-Cloud Telemetry: Edge devices capture edge cases, failed queries, or low-confidence predictions. Anonymized data streams back to cloud queues (Kafka, MQTT).
Continuous Adapter Sync: Serverless GPU workers execute automated micro-fine-tuning on the newly queued edge data, pushing updated lightweight LoRA adapters back to edge devices over-the-air (OTA).

Info

Serverless architecture unlocks low-power Edge GPUs and NPUs by replacing continuous, power-hungry background models with event-driven, sub-second inference micro-bursts. This eliminates thermal overload and battery drain on constrained edge devices while dynamically managing shared system memory.

There are few key-patterns design for Serverless GPU Inference

Micro-Wasm Event Activation (Cold Starts < 10ms): Edge Serverless function use lightweight WebAssembly Runtime (e.g: WasmEdge with WASI-NN) for instanly wake up by sensors, execute GPU/NPU Inference and easier to scale to zero memory state after complete.
Unified Memory Slicing: Embedded SoCs (like NVIDIA Jetson or NXP eIQ) share system RAM between the CPU and NPU/GPU. Serverless edge schedulers allocate memory frames on-the-fly per function invocation, preventing OOM crashes on devices with as little as 4GB–16GB total RAM.
Dynamic GGUF & Adapter Hot-Swapping: A single quantized base model (e.g., INT4 GGUF or ONNX runtime) remains resident in memory. Incoming serverless event triggers dynamically load tiny task-specific adapters (LoRA) or vision heads for OCR, anomaly detection, or voice commands without reloading the base engine.
Cascading Confidence Offload (Edge-to-Cloud Fallback): Edge serverless functions execute local inference for sub-10ms response times. If the local model’s confidence score falls below a set threshold, the function asynchronously offloads the raw frame or query to a Cloud Serverless GPU cluster (like vLLM on EKS/GKE) for high-precision validation.

Architectural Layer	Tools & Runtimes	Role in Edge Inference
Serverless Runtime	WasmEdge (WASI-NN), Spin, OpenFaaS Edge, K3s + Knative	Sub-10ms event triggers with a <10MB memory footprint
Edge Inference Engine	llama.cpp (GGUF), ONNX Runtime, TensorRT-Edge, ExecuTorch	Low-precision (INT4/FP16) execution on embedded silicon
Hardware Abstraction	Akri, NVIDIA JetPack, NXP eIQ	Discovers and exposes heterogeneous NPUs/GPUs to serverless workloads
Sync & Telemetry	MQTT (Mosquitto/EMQX), Apache Kafka, NATS	Handles async event triggers, edge telemetry, and OTA model adapter updates
With LF Edge (Linux Foundation) , unifies the fragmented Operational Technology (OT) hardware landscape. It provides open frameworks to discover, virtualize, and orchestrate edge nodes and IoT protocols.

LF Edge Project	Architectural Layer	Primary Function in the Edge AI Pipeline
Project EVE (Edge Virtualization Engine)	Bare-Metal Hardware Virtualization	Provides an immutable, zero-trust host OS with A/B dual-partition updates on bare-metal gateways.
EdgeX Foundry	OT/IT Interoperability Framework	Normalizes raw industrial sensor protocols (Modbus, BACnet, OPC-UA) into structured JSON/MQTT events.
Akri	K8s Resource Discovery	Automatically detects leaf devices (IP cameras, local NPUs, USB sensors) and presents them as K8s resources.
Open Horizon	Policy-Based Orchestration	Manages autonomous deployment and lifecycle updates of container/Wasm workloads across thousands of edge nodes.
Fledge / eKuiper	Stream Analytics & Filtering	Filters noise and processes high-frequency time-series data locally before passing key triggers to the AI engine.

Info

Edge computing is an infrastructure topology—executing compute near the data source—rather than a single software stack

Near Edge (Regional Gateways / MEC): Runs lightweight Kubernetes distributions (K3s, KubeEdge, MicroK8s) to orchestrate microservices and AI engines on multi-gigabyte industrial hardware.
Far Edge (Micro-Devices / SoCs): Bypasses Kubernetes entirely due to strict memory ( $\leq 1 GB$ ) and thermal power ( $5 - 15 W$ ) limits, relying on bare-metal hypervisors (Project EVE) and WebAssembly runtimes (WasmEdge with WASI-NN).
LoRA Mechanics on Edge: A quantized base model (e.g., INT4 Llama or Vision Transformer) sits permanently in local device RAM/NPU. Event-driven serverless triggers hot-swap lightweight task adapters (10MB–50MB LoRAs or ONNX heads) on demand without pulling gigabytes over metered cellular networks.

Here is the matrix for reflecting the Edge AI Solves Infrastructure problems

Industry	Core Problem at the Edge	Edge AI & Serverless Solution	Key Tools & Architecture
Telecom (5G/6G MEC & OpenRAN)	Cloud latency (>50ms) breaks real-time radio beamforming and dynamic network slicing across dense cell towers.	Near-Edge Multi-access Edge Computing (MEC) servers execute reinforcement learning (xApps) to reallocate radio bandwidth locally in sub-10ms loops.	K3s / KubeEdge, OpenRAN RIC, ONNX Runtime, DPDK
EV Charging Infrastructure	Concurrent fast-charging surges burn out local grid transformers, causing localized power outages.	Localized AI load-balancing algorithms run directly on charging station gateways. They adjust power output across 20+ piles in sub-second intervals, maintaining local stability even when offline.	WasmEdge, MQTT (Mosquitto/EMQX), Rust/Python micro-runtimes
Virtual Power Plants (VPP)	Centralized cloud controllers react too slowly to sub-second utility grid frequency spikes (50Hz/60Hz).	Edge controllers aggregate local solar inverters, battery storage, and smart HVACs. Local ML models adjust charge/discharge cycles in $< 100 ms$ to stabilize the grid locally.	Project EVE, EdgeX Foundry, Modbus/OPC-UA
Clean Power (Solar & Wind)	Remote solar and wind farms have poor satellite bandwidth and require sub-second hardware safety controls.	On-site edge vision and vibration models run on low-power NPUs to feather wind turbine blades during dangerous gusts or adjust solar panel angles based on local cloud movement.	WASI-NN, TensorRT-Edge, NXP eIQ, Local Time-Series DBs

Info

Across all four domains, the underlying blueprint remains identical: keep execution local for deterministic speed, and use serverless event triggers to swap lightweight model adapters without relying on a persistent cloud connection.

Explore couple of articles, papers about this topics and enjoyed

How I am implementing DIY Chatbot with Serverless

Why I choose Serverless

If you are exploring serverless architectures, I hope this breakdown offers valuable insights for your upcoming projects. Below is a solution showcase featuring a DIY Chatbot built using Cloudflare Workers and Cloudflare D1 to automate KPI management and workload tracking based on daily user activity.

But answer reason why, because I think that match with my requirments

Zero Server Management: Eliminates the operational overhead of managing VPS or dedicated server infrastructure. Designed with non-technical maintenance in mind, it simplifies configuration through managed compute boundaries.
Generous Free Tiers: Among the various architectural approaches, serverless platforms offer extensive free usage tiers. Cloudflare Workers serves as a highly cost-effective runtime for lightweight execution.
Seamless Messaging Platform Integration: Functioning as an event-driven webhook handler, serverless architecture integrates effortlessly with messaging services like Zalo or Telegram, ideal for asynchronous, user-triggered workflows.
Multi-Language & Framework Flexibility: Modern serverless runtimes offer flexible implementation choices across various languages and frameworks, particularly JavaScript/TypeScript and Python.

Based on these criteria, a serverless pattern implementing a Request-Response or API Proxy architecture serves as a refined, production-ready design for building automated chat workflows.

Choosing the right provider is a critical decision. While Cloudflare Workers was ultimately selected for edge performance, another compelling option considered during initial evaluation was Google Apps Script.

Apps Script

A rapid application development platform that makes it fast to create business applications that integrate with Google Workspace. You write code in modern JavaScript and have access to built-in libraries for Google Workspace applications like Gmail, Google Calendar, Google Drive, and more.

Following these features, I thought about that cool if I can use Google Sheet to DataStorage saving the both AppScript implemented by JavaScript, and also keep the data of workloads tracker and API Managment. With AppScript, you can perform not only Google Sheet, but futhermore like

Add custom menus, and dialogs & sidebars to Google Docs, Google Sheets, and Google Forms.
Write custom functions and macros for Sheets.
Publish web apps—either standalone or embedded in Google Sites.
Interact with other Google services, including Google AdSense, Google Analytics, Calendar, Drive, Gmail, and Google Maps.
Build lightweight add-ons and publish them to Google Workspace Marketplace. If you anticipate building large-scale add-ons, refer to Build a Google Workspace add-on using HTTP endpoints.

Not only building AppScript manually, but also Google provide clasp as CLI solution for helping you easier to delivery and update AppScript automatically. It provens more evidence to say that quite graduate solution to be setup. Explore more about Clasp & How to use for more usage.

Actual Problems

Google blocks it on managed accounts. The script needs sensitive OAuth scopes — spreadsheets and script.external_request — and an organisation account will refuse consent outright unless an admin allow-lists the script or the project is moved onto a GCP project with an Internal consent screen. Those scopes are irreducible here: it has to read a spreadsheet and it has to call the Zalo API.

Here is permission scopt I set for AppScript Project and get the block when running the function.

{
  "timeZone": "Asia/Ho_Chi_Minh",
  "dependencies": {
    "enabledAdvancedServices": [
      {
        "userSymbol": "Drive",
        "serviceId": "drive",
        "version": "v2"
      }
    ]
  },
  "exceptionLogging": "STACKDRIVER",
  "runtimeVersion": "V8",
  "webapp": {
    "executeAs": "USER_DEPLOYING",
    "access": "ANYONE_ANONYMOUS"
  },
  "oauthScopes": [
    "https://www.googleapis.com/auth/spreadsheets",
    "https://www.googleapis.com/auth/drive.file",
    "https://www.googleapis.com/auth/script.external_request",
    "https://www.googleapis.com/auth/script.scriptapp",
    "https://www.googleapis.com/auth/script.container.ui"
  ]
}

Due to the restrictions of Google Workspace permissions and GCP IAM via OAuth, I began considering an alternative approach. While this setup is beneficial for GCP-managed backends and I appreciate how it enhances ecosystem security, it demands significant time and effort for maintenance and upgrades. Consequently, I sought another solution, and Cloudflare’s serverless architecture, featuring Workers and their broader ecosystem, proved to be the right choice for successfully implementing this project.

Explore if you want to delve deeper into the combination between Google App Scripts with Google Sheet, you can check this video for more information Youtube - Google Apps Script for Beginners: Start Automating Google Sheets

Cloudflare Serverless Ecosystem

After spending some time exploring Cloudflare’s serverless offerings and ecosystem, my first impression is that their toolset is more than comprehensive. It provides extensive computing and serverless capabilities that seamlessly connect you with various services, such as the D1 database (SQLite) and R2 object storage. What ultimately led me to choose this platform—aside from it being one of the largest domain management systems—is that it offers the best generous free tier. It provides just the right amount of resources, allowing you to gracefully build small projects or experiment with your ideas within their ecosystem.

Double-check these articles hightlight below for more information about Cloudflare worker, Serverless compatible and free-tier with Cloudflare Free-tier Account.

Let’s delve deeper a little bit about CloudFlare Worker and Framework supported. You can explore deeply into it at Cloudflare Worker - Documentation

Cloudflare Workers

A serverless platform for building, deploying, and scaling apps across Cloudflare’s global network with a single command — no infrastructure to manage, no complex configuration

Following these both concept I related about Serverless and Edge Computing, CloudFlare worker is one of them, and with this architecture that allow Cloudflare can deploy to the end user close as possible, help these application reduce latency and increase performance.

Cloudflare also support several framework and also Serverless Framework, include

Full-stack framework: React, Vue, Svelte, Next, Astro, React Router, and more
Multiple-language prefered: JavaScript, TypeScript, Python, Rust, and more

With diverse optional, I think you can deploy what ever you want from Front-end application (static-asset), backend-application (API), AI-Inference, Background jobs, and more stuff about Observability & Monitoring integrated

Not only that, Workers like I told that allow you to connect with several compute and storage services of Cloudflare like

Cloudflare D1: Cloudflare’s managed, serverless database with SQLite’s SQL semantics, built-in disaster recovery, and Worker and HTTP API access.
Cloudflare R2: Object storage for all your data. Egress bandwidth fees associated with typical cloud storage services.
Cloudflare Queues: Send and receive messages with guaranteed delivery and no charges for egress bandwidth.
Cloudflare Cache/CDN: Global CDN for rapid access static-content with high-performance.
And moreover

Moreover, Cloudflare worker provide several highlighted feature, like

Versioning & Deployments: Versioning each deployment version for archive or running with unique ID, and using them to proceed Canary Deployment by spliting traffic across version with Gradual Deployments
wrangler CLI: Cloudflare worker CLI allowed you for run and configuration Cloud worker & page without access into Cloudflare dashboard, used this one for CI/CD pipeline, and handle multiple queries to compute and data storage of Cloudflare, e.g: Database D1.
Observability: Provide you full ecosystem to help you debug, analysis and understand your project under the control for following ingest request.

Quote

Throught to these features, Cloudflare workers and ecosystem enable all-in-one (AIO) system completely from code to application, database and deployment as life-cycle. I would to recommend find out to Cloudflare if you want to handle simple project, or serverless architecture.

Zalo Chatbot Platform

Let’s tell a abit about Zalo Chatbot Platform, and see what it got behind

Zalo Chatbot Platform

A comprehensive chatbot platform that empowers developers to seamlessly integrate bots into Zalo chats through straightforward and simple steps.

FYI

Zalo is Vietnam’s leading messaging platform. Initially released on August 8, 2012, by VNG Corporation, it has emerged as one of Vietnam’s prominent tech unicorns. With nearly every citizen utilizing it for both professional communication and daily life, it stands as a source of national pride, deserving a major shoutout. Furthermore, Zalo integrates with various external tools and services, such as news outlets, banking, and flight bookings, transforming the platform into a comprehensive ecosystem for managing diverse tasks.

Based on these considerations and daily usage requirements, using the Zalo Chatbot Platform proved to be the best fit for this project. Although in an early stage, Zalo’s free tier is generous for small projects, supporting up to 3 group chats and interactions with up to 50 users. It provides a cost-effective, straightforward solution for both technical and non-technical teams to build automated bots for daily task management.

To explore more about the Zalo Chat Platform, refer to these official resources:

Create a bot: Step-by-step guide to provisioning your bot.
Using the API: Comprehensive API references and invocation methods.
Webhook: Webhook payload specifications and endpoint registration guidelines.

Currently, the Zalo Bot platform supports two primary mechanisms for receiving and processing messages with your backend:

Long Polling: Periodically polls the server for new incoming messages.
Webhook: Zalo automatically pushes event payloads to your registered HTTP endpoint.

For this setup, the Webhook approach is the optimal choice. It aligns seamlessly with serverless execution models by processing event-driven HTTP requests and returning immediate responses. You can explore further best practices and API reference details in the official documentation.

To get started, create your bot following the setup steps to obtain your bot token in the format 12345689:abc-xyz. Once obtained, you are ready to register your webhook URL using the API structure below.

 https://bot-api.zaloplatforms.com/bot${BOT_TOKEN}/functionName

Wire them together

Disclaim

Because of the source-code related some sentitive information, so I can’t directly to share it. But I will try hard to be go in to detail to let you know how to build and setup by yourself.

First of all here is the code structure of project

├── package.json
├── package-lock.json
├── public
│   └── vendor
├── README.md
├── schema.sql
├── src
│   ├── bot.js
│   ├── crypto.js
│   ├── import.js
│   ├── index.js
│   ├── pages
│   ├── review.js
│   ├── score.js
│   ├── store.js
│   ├── template-spec.js
│   └── zalo.js
├── test
│   ├── harness.mjs
│   └── worker.test.mjs
└── wrangler.toml

wrangler.toml: Because we will use wrangler to deploy the application, so that one required for storing configuration, and worker setup
src: The entire source-code of project
schema.sql: The schema of database D1 for migrating the schema for initialization
package.json: As you know you know, NodeJS package managament
public/vendor: I use exceljs for helping excel generation runs in the browser, this public will store this script to release the heavy library out of workers. exceljs is served from this Worker’s own origin (public/vendor/), never a CDN, because the unit’s network may block external hosts.

File	Responsibility
`src/template-spec.js`	anchor rules — ported from Apps Script with zero logic changes, still covered by the same 66 assertions
`src/store.js`	all D1 access; the designated swap point
`src/zalo.js`	Bot API client, 2000-char chunking, retry on 429/5xx
`src/crypto.js`	HMAC + constant-time compare on WebCrypto
`src/bot.js`	commands and the logging grammar
`src/review.js`	signed links, period lock, page model
`src/import.js`	SheetJS reads .xls/.xlsx → anchors → D1
`src/score.js`	KPI formulas
`src/pages/*`	review, export and admin pages
Because I don’t use any framework for this deployment, it’s truly serverless with only the function implementation for several routes, and this one can work perfectly in Zalo for responding by Javascript Language and few examples in Javascript for easier following.

There are some configuration of project, that able to show, including

{
  "name": "kpi-zalo-worker",
  "private": true,
  "type": "module",
  "scripts": {
    "dev": "wrangler dev",
    "deploy": "npm run vendor && wrangler deploy",
    "vendor": "cp node_modules/exceljs/dist/exceljs.min.js public/vendor/",
    "db:create": "wrangler d1 create kpi",
    "db:init": "wrangler d1 execute kpi --remote --file=./schema.sql",
    "db:init:local": "wrangler d1 execute kpi --local --file=./schema.sql",
    "test": "node --experimental-sqlite test/worker.test.mjs ../samples/grid.json"
  },
  "dependencies": {
    "xlsx": "^0.18.5"
  },
  "devDependencies": {
    "exceljs": "^4.4.0",
    "wrangler": "^4.125.0"
  }
}

name = "kpi-zalo-bot"
main = "src/index.js"
compatibility_date = "2026-01-01"
 
# SheetJS parses the uploaded .xls server-side and wants a few Node builtins.
compatibility_flags = ["nodejs_compat"]
 
# worker.dev mode is not used and maybe lead to abuse domain errors, so we disable it. The custom domain is used instead.
workers_dev = false
preview_urls = false
 
# (opt) prevent the error when request with the abuse domain `worker.dev`, custom domain is used instead
routes = [
    { pattern = "abcd.example.com", custom_domain = true }
]
 
[[d1_databases]]
binding = "DB"
database_name = "kpi"
database_id = "<replace-by-your-id-init>"   # wrangler d1 create kpi
 
# exceljs is served from this Worker's own origin, not a CDN: the unit's
# network may block external CDNs, and the export page must not depend on one.
[assets]
directory = "./public"
binding = "ASSETS"
 
 
[vars]
TIMEZONE = "Asia/Ho_Chi_Minh"
# (opt) PUBLIC_URL = "https://abcd.example.com"
# Secrets are NOT here. Set them with `wrangler secret put`:
#   ZALO_BOT_TOKEN       from the Zalo Bot Manager OA
#   WEBHOOK_SECRET       8-256 chars per the Bot API docs; also sent to
#                        setWebhook. `openssl rand -hex 24` is a safe default.

Explore more about Wrangler Configuration and Wrangler Configuration File

Let’s talk a bit about mechanism how worker ship your code toward

Info

wrangler use the mechanism call bundle same as method you run when ship the static code for production environment with project like react or vite. The package to help you bundle called esbuild

In the configuration file, I set the entry point to the root file (main = "src/index.js"). wrangler reads this file, finds all imported modules, and resolves their specifiers. Before combining them into a single bundled file, it resolves package dependencies like xlsx via Node resolution into node_modules/xlsx (landing on xlsx.mjs per its exports map). This repeats transitively until no new dependencies appear.

After that, it compresses the bundled script with gzip to downscale the code size and uploads it along with metadata (bindings for DB, ASSETS, VARS, and Secrets) to the Cloudflare API as a multipart upload. At the edge, It’s stored as one script and instantiated in a V8 Isolate. It’s why bundle size matters for cold start more than for bandwidth

V8 Isolate Instantiation & The Cold Start Impact

Cloudflare Workers execute inside V8 Isolates rather than full virtual machines or Docker containers:

Zero-OS Boot Overhead: Traditional containerized FaaS (like AWS Lambda) must allocate virtual CPU, memory, and an operating system runtime during a cold start. V8 Isolates run thousands of separate scripts inside a shared process, eliminating OS-level startup delay.

Why Bundle Size Dictates Cold Starts: In an isolate architecture, cold-start latency is driven almost entirely by V8 script parsing and compilation time, not network transfer speed. A larger JavaScript bundle requires V8 to parse and evaluate more syntax trees before executing the first line of code, directly increasing execution latency.

Warning

Dynamic imports break the graph. esbuild resolves import statically. await import(someVariable) can’t be followed, so the target won’t be inlined and will fail at runtime. Everything in src/ is static, which is why this has never bitten you.

Your dependencies vs devDependencies split is doing nothing for size. What ships is decided purely by reachability from src/index.js. xlsx sits in dependencies and exceljs in devDependencies, and that’s honest bookkeeping — but moving xlsx to devDependencies wouldn’t shrink the bundle by a byte, and it would still ship.

Anyway, if you want to explore more about how worker worked, check this out Cloudflare - How Workers works

Now let’s run each command to fully deploy project

Install wrangler

npm install

Create the database D1 and replace ID in wrangler.toml before running the migration with defined schema at schema.sql

npm run db:create              # copy the printed database_id into wrangler.toml
npm run db:init

Wrangler support both VARS import by configuration file for publish environment variable, and secret with command to keep them securable

npx wrangler secret put ZALO_BOT_TOKEN        # from the Zalo Bot Manager OA
npx wrangler secret put WEBHOOK_SECRET        # 8-256 chars: openssl rand -hex 24

Now run the deploy and ship the code

npm run deploy

Opt

If you use the custom-domain, you can deploy again with new env PUBLIC_URL, so help the bot can use custom domain to review it when setWebhook

Already you already setup full serverless in edge computing of Cloudflare with Cloudflare worker.

Now register the Zalo Bot with Webhook with curl command to set webhook

curl -X POST "https://bot-api.zaloplatforms.com/bot<BOT_TOKEN>/setWebhook" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-custom-domain.example.com",
    "secret_token": "mykey-abcyxz"
  }'

Failure

Here is problem come, because Cloudflare will block the request from anonymous or strange browser or user-agent for severity check-up.

{
  "ok": true,
  "result": {
    "ok": false,
    "url": "https://your-webhookurl.com",
    "status_code": 403,
    "outcome": "webhook.http.403",
    "latency_ms": 189,
    "hint": "Your server or CDN rejected the request with 403. Check WAF / Cloudflare rules, any IP allowlist, and that the User-Agent \"Java/<version>\" is permitted."
  }
}

Therefore, I cost one or two hours to debug with enable Log and check the error, and that lead into the Issue: Browser Integrity Check, it doesn’t issue, it just the feature of Cloudflare to ensure connection come from external resources for prevent DDoS or Anomaly Activity, e.g: Bots, Crawlers, … with challgenges.

In badly, Zalo bot use User-Agent: Java/<version> to send the request and it hits Browser Integrity Check rejects with a 403 at the edge — before the Worker runs.

To fix it, you need to define the additional rule for help you bypass this one for only Zalo Bot, with turn off Browser Integrity Check

Warning

I don’t recommend the method to turn off the Browser Integrity Check entirely, because it make your domain and other service can encounter the abuse activity by anomaly activity.

You can find the configuration at Your Domain → Rules → Overview → Create Rule (Configuration Rules) with

Expression: (http.host eq "your-custom-domain.example.com")
Setting: Browser Integrity Check → Off

Now try again with register webhook /setWebhook and /testWebhook for checkup again

{
  "ok": true,
  "result": {
    "ok": true,
    "url": "https://your-custom-domain.example.com",
    "status_code": 200,
    "outcome": "webhook.ok",
    "latency_ms": 214,
    "hint": "Your endpoint responded successfully."
  }
}

Now you can test from Zalo Application to get the whole conversation with your Serverless via message.

Conclusion

center

My Thoughts

That’s it, damn. It seemed easy at first, but there was a lot more information to digest than I initially thought. Anyway, taking a step back, you can gain a deeper understanding and knowledge of Serverless Architecture, design patterns, and some new keywords, such as Edge Computing or AI/ML on Serverless. Beyond that, I found the experience of trying to implement something new, learning a couple of serverless concepts, and handling them with Cloudflare Workers to be quite remarkable and engaging.

Quote

Well, it’s been a long time, maybe six months 😮‍💨,since I last tried to write a full blog post about a DIY project, and the feeling is just like the old days: fantastic. I hope you gain valuable insights and knowledge about Serverless and take some time to enjoy exploring it before trying it out for yourself. By the way, I hope this blog helps keep my motivation alive; I plan to publish several more articles by the end of the year, so hopefully, those will be out soon. Finally, I hope you and your family are doing well. I hope everyone in my country has a wonderful holiday, and that the rest of you have a fantastic weekend. Stay tuned, and I’ll see you soon, y’all. Bye!

xeusnguyen.xyz

Explorer

Recent Notes

About Serverless Discovery - DIY Chatbot Serverless with Cloudflare Worker + D1

Awesome Kafka & MQTT

Awesome Utilities Sites

About Serverless Discovery - DIY Chatbot Serverless with Cloudflare Worker + D1

Serverless Architecture and The story surround them

Why Serverless

The Advantage and Trade-off

Serverless in System Architecture Design

Request-Response / API Proxy Pattern

Fan-Out / Pub-Sub (Event-Driven) Pattern

Queue-Based Buffer

Saga / Step Orchestration Pattern

Choreography Pattern

CQRS (Command Query Responsibility Segregation) Pattern

Strangler Fig Pattern

Conclusion

AI and LLM with Serverless Architecture 2026

Queue-Based Buffer + Event-Driven Scaling (The GPU Optimizer)

Saga / Step Orchestration (The Agentic AI & Pipeline Engine)

CQRS (The RAG & Knowledge Indexing Engine)

Streaming Request-Response (Real-Time LLM Serving)

Low-Latency Interactive Inference (Buffered Scale-to-Zero)

Dynamic LoRA Hot-Swapping (Multi-Tenant Base Instance)

Conclusion

Bonus: Cloud Native, Edge Computing with Serverless

How I am implementing DIY Chatbot with Serverless

Why I choose Serverless

Cloudflare Serverless Ecosystem

Zalo Chatbot Platform

Wire them together

Conclusion

Graph View

Table of Contents

Backlinks