DEV Community: Pedro Oliveira

A 100% Serverless WhatsApp Agent: Go + AWS Lambda + EventBridge

Pedro Oliveira — Thu, 11 Dec 2025 02:57:41 +0000

Building a WhatsApp Cloud API Agent on AWS Lambda Using Go

In this post I want to share how we designed a WhatsApp Cloud API agent that is 100% serverless, built with Go and AWS. The goal was to keep costs extremely low while still being ready for large-scale message traffic.

The project powers an automated commercial agent for Barx, talking to customers over WhatsApp, powered by OpenAI Agents behind the scenes.

High-level architecture

Everything runs serverlessly on AWS:

API Gateway HTTP API (v2): single entry point for the WhatsApp webhook and auxiliary endpoints (verification + Swagger).
Lambda functions (Go, provided.al2023):
- wpp-verification: handles the Webhook verification challenge from WhatsApp Cloud API (GET /webhook/messages).
- messages-webhook: receives incoming messages (POST /webhook/messages), validates & normalizes payloads, and schedules answer processing.
- answer-handler: processes messages in batch, calls the OpenAI Agent workflow, and sends responses back to WhatsApp.
- swagger-ui / get-swagger: serve API docs for internal use.
Amazon EventBridge Scheduler: used as a buffer + delay mechanism to decouple message ingestion from answer generation.
DynamoDB: single table (referenced by name from CDK) storing messages, conversation memory, and related entities.
AWS Secrets Manager: stores WhatsApp Cloud API credentials and related secrets (token, phone number ID, API version, etc.).

The CDK stack (cdk/lib/serverless-go-app-stack.ts) wires all of this:

Creates the HTTP API and routes to each Lambda via HttpLambdaIntegration.
Injects common environment variables into each Lambda (stage, region, table name, secret name, OpenAI API key).
Grants fine-grained IAM permissions:
- secretsmanager:GetSecretValue only for the configured secret.
- dynamodb:PutItem, GetItem, UpdateItem, etc. only on the WhatsApp agent table.
- EventBridge Scheduler permissions for the webhook Lambda to create/update/delete schedules and iam:PassRole for the scheduler role.
Reuses log groups with a short retention (3 days) to control CloudWatch costs.

Code architecture (clean-ish layers)

The Go service is structured in layers under services/agent:

internal/application: use cases (orchestrators) for each business flow.
internal/domain: entities and repository interfaces.
internal/infra: concrete implementations (WhatsApp client, OpenAI agent, DynamoDB repositories, scheduler, config, logging).
internal/interface/http: HTTP/Lambda controllers that adapt API Gateway events to use cases.

Incoming messages flow

WhatsApp Cloud API sends a POST to /webhook/messages.
API Gateway forwards it to the messages-webhook Lambda.
receive_message controller (internal/interface/http/receive_message/controller.go):
- Logs the raw payload.
- Unmarshals into a WhatsAppWebhook model.
- Maps it into one or more ReceiveMessageCommand values.
- For each command, calls ReceiveMessageUseCase.Execute.
ReceiveMessageUseCase (internal/application/receive_message/use_case.go):
- Persists the message in a MessageRepository (backed by DynamoDB).
- Schedules an answer using a SchedulerAnswerRepository that wraps EventBridge Scheduler.
- If a schedule already exists, it handles ConflictException and updates the schedule instead of failing.

The key idea: every message creates (or updates) a schedule that will later trigger answer-handler with the serialized Message as input. This naturally batches multiple messages from the same user within a short window and avoids hammering OpenAI for each keystroke.

Answer generation flow

EventBridge Scheduler invokes the answer-handler Lambda with the serialized Message.
answerUseCase (internal/application/answer/use_case.go):
- Sends a typing indicator via WhatsApp Cloud API to improve UX.
- Loads conversation memory from a MemoryRepository (DynamoDB).
- Lists pending user messages for that user ID.
- Concatenates the messages into a single prompt and calls the Agent client (AgentClient) wrapping openai-agents-go.
- Saves back the new LastResponseID to memory to keep the conversation context alive.
- Sends one or more WhatsApp text messages with the agent’s answer.
- Deletes processed user messages in batch.

WhatsApp Cloud API client

internal/infra/whatsapp/client.go implements CloudAPIRepository:

Reads WhatsApp Cloud API settings from Secrets Manager (version, phone number ID, access token).
Sends text messages and typing indicators by POSTing JSON payloads to the Graph API.
Logs both error states and successful responses, but returns simple Go errors to the application layer.

OpenAI Agent integration

internal/infra/agent/client.go integrates with openai-agents-go:

Defines a typed SchemaOutput describing the structured response (messages[] { content }).
Configures the Agent with:
- Name and instructions (AgentInstructions) tailored to the Barx commercial assistant.
- Model (gpt-5 in this codebase), reasoning settings, and metadata.
- Tools: file search (vector store) and web search constrained to barx.com.br.
Exposes a RunWorkflow method that returns a generic AgentOutput[SchemaOutput] with both the response and LastResponseID to keep the conversation thread.

Why 100% serverless?

This architecture was intentionally designed to be fully serverless:

No containers, no servers to manage.
Scale-to-zero behavior: when there is no WhatsApp traffic, there are essentially no compute costs.
Cloud-native services (API Gateway, Lambda, EventBridge Scheduler, DynamoDB, Secrets Manager) all scale horizontally with traffic.

Because of this, we can support:

Spiky traffic (promotions, campaigns, peak hours) without pre-provisioning instances.
Long-tail usage across many establishments, each generating low but unpredictable traffic.

Pros of this architecture

Cost-efficient: pay-per-invocation Lambdas + DynamoDB on-demand + short log retention keep monthly costs under control, especially for early-stage products.
Naturally scalable: API Gateway + Lambda + EventBridge Scheduler handle thousands of concurrent conversations without manual tuning.
Resilient conversation pipeline: storing messages and memory in DynamoDB plus scheduled triggers means transient failures usually don’t lose user messages.
Clean separation of concerns:
- interface/http for Lambda controllers
- application for orchestration
- domain for entities and interfaces
- infra for AWS + external integrations (WhatsApp, OpenAI, Secrets Manager, DynamoDB, Scheduler)
Vendor-optimized integrations: using EventBridge Scheduler for delayed processing instead of hand-rolled CRON, and Secrets Manager for credentials, keeps security and operations simpler.

Cons and trade-offs

Cold starts: Go on Lambda is generally fast, but with multiple functions (webhook, answer handler, Swagger) you can still feel cold start latency for very low-traffic tenants.
Distributed debugging: tracing a single user interaction across API Gateway, Scheduler, multiple Lambdas, and DynamoDB can be harder than in a monolithic app unless you invest in end-to-end observability.
Operational complexity at the cloud layer: IAM, Scheduler permissions (iam:PassRole), secrets, and environment variables must all be configured correctly; CDK helps, but misconfigurations can be subtle.
Limited local emulation: fully reproducing API Gateway + Scheduler + WhatsApp Webhooks locally is non-trivial; most realistic testing still happens in the cloud.
Tight coupling to AWS: the design uses AWS-native services heavily (Scheduler, Secrets Manager, DynamoDB, Lambda), so moving to another cloud would require a serious rewrite.

What would you improve?

This architecture has worked well for us so far: low cost, simple scaling, and a clean Go codebase with clear boundaries between HTTP, application, domain, and infrastructure.

If you’ve built something similar (WhatsApp bots, agentic backends, or serverless messaging pipelines), I’d love to hear from you:

How would you improve this design?
What would you change to make it more resilient or easier to operate?
Any patterns you recommend for observability or testing in this kind of serverless setup?

Share your thoughts, ideas, or questions in the comments — I’m happy to iterate on this architecture with the community’s feedback.

How I Designed a Zero-Waste, Event-Driven Analytics Pipeline Using DynamoDB TTL and AWS Lambda

Pedro Oliveira — Thu, 11 Dec 2025 02:14:52 +0000

It is time to get the data Barx is generating and bring it to the barbers. My first option was to create a cron job that runs every Monday at 3 am UTC. When my lambda triggers, I search for all barbershops in DynamoDB and start the analytics calculation for each one.

However, this approach presents some resource and cost challenges:

Scanning the entire DynamoDB table is resource-intensive and can be costly.
A single lambda function handles a heavy workload, which may impact performance and scalability.
Every Monday, the process attempts to retrieve all barbershops, regardless of their activity status.
Analytics calculations are performed for all barbershops, including those without any activity in the previous week, leading to unnecessary resource consumption.

Probably there are more problems, but I won't ask for AI to make it more dramatic...

The point is, I would like to be able to spend resources only with those barbershops that had activities from last week and recalculate their analysis regarding the last 7, 30, 60, and 90 days.

The architecture proposal

Thinking on that, I built this architecture:

It looks simple, but it helps me to schedule a job only for those barbershops that had some activity, so I create a record in DynamoDB to expire next Monday at 3 am UTC.

When the record is deleted because TTL rule, it triggers another lambda that shares the data of that barbershop that was scheduled to start in a dedicated lambda for its analytic calculation.

This approach helps me to spend resources only with users who are producing data, not those who are not producing.

Benefits I thought:

Analytics calculations are performed only for barbershops with recent activity, optimizing resource usage.
Scheduled records in DynamoDB are automatically cleaned up via TTL, reducing manual maintenance.
The architecture scales efficiently, supporting any number of users without additional complexity.

Preocupations I have:

If many records expire at the same time, a large number of lambdas may be triggered simultaneously, leading to a spike in concurrent executions. (But I can handle this, configuring better DynamoDB Stream batch size and parallelization factor).
There may be a delay between the scheduled expiration time and the actual triggering of the lambda, depending on the load on the DynamoDB Streams service. (This is acceptable for my use case since analytics don't need to be real-time).

My intention in posting this article is to share my idea and get feedback from the community. If you have any suggestions for improvement or alternative approaches, please let me know in the comments!

Minimal changes when migrating react-scripts to vite

Pedro Oliveira — Tue, 27 Aug 2024 23:07:13 +0000

🇧🇷 Pra quem quiser ver as alterações necessárias da migração do sistema de build react-scripts para vite em um projeto reactjs pequeno, segue o commit, o commit a seguir é de um pequeno projeto público:

https://github.com/pedroSoaresll/make-your-list/commit/e4bcf8e6d19637e0f49f491a13a43a4756f0dbc4

🇺🇸 If you wish to see the needed changes when migrating react-scripts to vite system build, take a look at this git commit, it is related to a small project:

https://github.com/pedroSoaresll/make-your-list/commit/e4bcf8e6d19637e0f49f491a13a43a4756f0dbc4

Invoking Web Worker as a module

Pedro Oliveira — Tue, 30 Apr 2024 15:52:48 +0000

Uau, I didn't know about that but all indicates that it is possible to load web worker directly as a module.

Before, I was loading the script via HTTP passing the public path, note that I am using a React application with Vite.

Old example:

I didn't like this way of loading web workers because I was forced to write it as a javascript file, and I couldn't import other modules inside that. Take a look:

Web Worker script: public/get-merchant-ids-from-csv.js

self.onmessage = function handleMessageFromMain(message) {
  /**
   * @type {File}
   */
  const file = message.data;
  const result = new FileReader();
  result.readAsText(file);
  result.onloadend = function () {
    const merchantIds = extractValues(result.result);
    self.postMessage(merchantIds);
  };
};

function extractValues(result) {
  const [, ...rows] = result.split('\n');
  const values = rows.map((row) => {
    const items = row.split(',');
    return items.reduce((_, item, index) => {
      return String(item).trim();
    }, []);
  });
  return values;
}

Invoking the web worker from the public directory

// NOTE: In my case I needed to specify the base URL, but in most of cases you can write the URL starting with "/"
const GET_MERCHANT_IDS_FROM_FILE_WORKER = `${BASE_URL}/get-merchant-ids-from-csv.js`;
const worker = new Worker(GET_MERCHANT_IDS_FROM_FILE_WORKER);

Prefered way example:

Web worker script: src/modules/shared/workers/get-merchant-ids-from-csv.ts

Note that it is a typescript now

self.onmessage = function handleMessageFromMain(message: MessageEvent<File>) {
  const file = message.data;
  const result = new FileReader();
  result.readAsText(file);
  result.onloadend = function () {
    const merchantIds = extractValues(String(result.result));
    self.postMessage(merchantIds);
  };
};

function extractValues(result: string) {
  const [, ...rows] = result.split('\n').map((row) => row.trim());
  return rows;
}

The new way of importing the web worker:

const worker = new Worker(
  new URL(
    '../../shared/workers/get-merchant-ids-from-csv.ts',
    import.meta.url,
  ),
  {
    type: 'module',
  },
);

Now, it is possible to import other modules, and independent of the place where the script is located, we can inform the path and import it. Note that it is important to pass as a second parameter the base URL import.meta.url (exposed by vite build system)