Forem: Cláudio Filipe Lima Rapôso

Practical Guide: Building an Active-Active Multicloud Cell-Based Architecture

Cláudio Filipe Lima Rapôso — Thu, 23 Apr 2026 03:00:00 +0000

1. Introduction

A multicloud cell-based architecture represents the pinnacle of fault isolation and vendor neutrality. By distributing autonomous "cells" across different cloud provider, such as placing Cell Alpha in AWS and Cell Beta in Azure, you eliminate the risk of a single cloud provider's regional or global outage taking down your entire application. At the end of this tutorial, you will understand how to provision a unified control plane that intelligently routes tenant traffic to entirely isolated data planes residing in disparate cloud ecosystems.

This architecture is highly valuable for organizations with extreme availability requirements and strict regulatory compliance mandates. It prevents vendor lock-in by enforcing an agnostic ingress layer and identical compute/state contracts across clouds. Building this requires mature infrastructure as code practices and a deep understanding of decoupled domain boundaries.

2. Prerequisites

To execute this architectural pattern, you must have the following tools and access configured:

Active accounts on both Amazon Web Services (AWS) and Microsoft Azure, with administrative credentials.
Terraform (version 1.0+) installed locally, with both hashicorp/aws and hashicorp/azurerm providers authenticated.
Python (version 3.11+) for writing the agnostic edge routing logic.
A registered domain name and access to a neutral Edge DNS provider (e.g., Cloudflare) to act as the global entry point.
Understanding of Domain-Driven Design (DDD) to ensure cell workloads are completely bounded and stateless.

3. Step-by-Step

A multicloud cellular architecture requires a strict separation between the "Control Plane" (which knows where tenants live) and the "Data Plane" (where the actual compute and storage happen). The sequence diagram below illustrates how an edge router evaluates the request and proxies it to the respective cloud provider.

3.1 Configuring the Multicloud Terraform Environment

What to do: Create a root Terraform configuration that initializes both the AWS and Azure providers simultaneously.
Why do it: To manage a true multicloud infrastructure, your CI/CD pipeline must be able to orchestrate state across both environments from a single source of truth, ensuring that the infrastructure contracts remain identical.

Example:
Create your main.tf file to authenticate both providers:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
  alias  = "primary"
}

provider "azurerm" {
  features {}
  subscription_id = var.azure_subscription_id
}

variable "azure_subscription_id" {
  type        = string
  description = "Azure Subscription ID for the multicloud landing zone"
}

3.2 Provisioning the AWS Cell (Cell Alpha)

What to do: Deploy the AWS-specific data plane, consisting of an API Gateway, Lambda, and DynamoDB.
Why do it: This establishes your first isolated failure domain. The AWS cell acts as a self-contained unit capable of serving its assigned tenants without any dependency on the central control plane or the Azure cell.

Example:
Append the AWS cell definition to your main.tf:

# AWS Cell Infrastructure (Simplified)
resource "aws_dynamodb_table" "aws_cell_state" {
  provider       = aws.primary
  name           = "multicloud-state-aws-alpha"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "id"

  attribute {
    name = "id"
    type = "S"
  }
}

resource "aws_lambda_function" "aws_cell_worker" {
  provider      = aws.primary
  filename      = "aws_worker.zip"
  function_name = "aws-worker-alpha"
  role          = aws_iam_role.aws_exec_role.arn
  handler       = "worker.handler"
  runtime       = "python3.11"
}

resource "aws_lambda_function_url" "aws_ingress" {
  provider           = aws.primary
  function_name      = aws_lambda_function.aws_cell_worker.function_name
  authorization_type = "NONE" # In production, restrict to Edge Router IPs/Tokens
}

output "aws_cell_endpoint" {
  value = aws_lambda_function_url.aws_ingress.function_url
}

3.3 Provisioning the Azure Cell (Cell Beta)

What to do: Deploy the Azure-specific data plane, consisting of an Azure Function and Cosmos DB.
Why do it: This creates the second failure domain in a completely separate physical network and control plane. If AWS experiences a major outage, the tenants assigned to the Azure cell experience zero degradation.

Example:
Append the Azure cell definition to your main.tf:

# Azure Cell Infrastructure (Simplified)
resource "azurerm_resource_group" "az_cell_rg" {
  name     = "rg-multicloud-beta"
  location = "East US"
}

resource "azurerm_cosmosdb_account" "az_cell_db" {
  name                = "db-multicloud-az-beta"
  location            = azurerm_resource_group.az_cell_rg.location
  resource_group_name = azurerm_resource_group.az_cell_rg.name
  offer_type          = "Standard"
  kind                = "GlobalDocumentDB"

  geo_location {
    location          = azurerm_resource_group.az_cell_rg.location
    failover_priority = 0
  }
  consistency_policy {
    consistency_level = "Session"
  }
}

resource "azurerm_storage_account" "az_storage" {
  name                     = "stmulticloudbeta"
  resource_group_name      = azurerm_resource_group.az_cell_rg.name
  location                 = azurerm_resource_group.az_cell_rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_service_plan" "az_plan" {
  name                = "plan-multicloud-beta"
  location            = azurerm_resource_group.az_cell_rg.location
  resource_group_name = azurerm_resource_group.az_cell_rg.name
  os_type             = "Linux"
  sku_name            = "Y1"
}

resource "azurerm_linux_function_app" "az_cell_worker" {
  name                       = "func-az-worker-beta"
  location                   = azurerm_resource_group.az_cell_rg.location
  resource_group_name        = azurerm_resource_group.az_cell_rg.name
  service_plan_id            = azurerm_service_plan.az_plan.id
  storage_account_name       = azurerm_storage_account.az_storage.name
  storage_account_access_key = azurerm_storage_account.az_storage.primary_access_key

  site_config {
    application_stack {
      python_version = "3.11"
    }
  }
}

output "az_cell_endpoint" {
  value = "https://${azurerm_linux_function_app.az_cell_worker.default_hostname}/api/process"
}

3.4 Developing the Agnostic Edge Router (Python)

What to do: Write the Python routing logic that will be deployed to a neutral edge layer (like Cloudflare Workers via Pyodide, or a dedicated edge Kubernetes cluster).
Why do it: You cannot host the global router inside AWS or Azure. If you host it in AWS and AWS goes down, your clients cannot reach the Azure cell because the router itself is dead. The routing layer must be cloud-agnostic.

Example:
Create global_router.py. This script intercepts the payload, queries the registry, and proxies the request across the internet backbone to the appropriate cloud.

import json
import urllib.request
import os

# The global registry maps tenant IDs to specific cloud cell endpoints.
# In production, this data is fetched from a distributed edge database.
GLOBAL_REGISTRY = {
    "T-100": {
        "provider": "aws",
        "url": os.getenv("AWS_CELL_ENDPOINT", "https://aws-api-mock.com/process")
    },
    "T-200": {
        "provider": "azure",
        "url": os.getenv("AZ_CELL_ENDPOINT", "https://az-api-mock.com/api/process")
    }
}

def route_request(request_body: str) -> dict:
    try:
        payload = json.loads(request_body)
        tenant_id = payload.get("tenant_id")

        if not tenant_id:
            return {"status": 400, "body": "Missing tenant_id"}

        # 1. Lookup tenant location in the registry
        cell_info = GLOBAL_REGISTRY.get(tenant_id)
        if not cell_info:
            return {"status": 404, "body": "Tenant not allocated to any cell"}

        target_url = cell_info["url"]
        provider = cell_info["provider"]

        # 2. Proxy request to the specific cloud provider
        req = urllib.request.Request(
            target_url,
            data=request_body.encode('utf-8'),
            headers={'Content-Type': 'application/json', 'X-Multicloud-Auth': 'EdgeToken123'}
        )

        with urllib.request.urlopen(req, timeout=5) as response:
            cell_response = response.read().decode('utf-8')

        # 3. Return payload to client with multicloud diagnostic headers
        return {
            "status": 200,
            "headers": {
                "X-Processed-By-Cloud": provider
            },
            "body": cell_response
        }

    except Exception as e:
        return {"status": 500, "body": f"Edge Routing Failure: {str(e)}"}

4. Common Troubleshooting

Operating a multicloud cellular architecture introduces extreme networking and data synchronization complexities. Be prepared to address the following challenges:

State Fragmentation and Global Reporting:
- Problem: Your business intelligence team cannot run global queries because data is split between AWS DynamoDB and Azure Cosmos DB.
- Solution: Do not attempt real-time federated queries across clouds. Implement a unified Data Lake (e.g., Snowflake or Databricks). Configure both the AWS Lambda and the Azure Function to asynchronously stream their state changes (Event Sourcing) into this central analytical repository.
Cross-Cloud Latency at the Routing Layer:
- Problem: If the neutral Edge Router has to query a database in AWS to find out that a tenant belongs in Azure, the latency overhead becomes unacceptable.
- Solution: The Tenant Registry must be cached at the edge. Utilize technologies like Cloudflare KV, Fastly Compute dictionaries, or Redis Enterprise Active-Active to ensure the routing metadata is geographically local to the Edge Router executing the Python script.
CI/CD Configuration Drift:
- Problem: Over time, developers add features to the AWS cell but forget to implement the exact Azure equivalent, breaking the "identical cell" contract.
- Solution: Enforce strict Hexagonal Architecture within your Python applications. The core domain logic must be a pure Python package shared across both clouds. The only differing code should be the specific I/O adapters (DynamoDB vs. Cosmos DB connectors).

5. Conclusion

By implementing a multicloud cell-based architecture, you have constructed the ultimate defense against cloud-provider lock-in and catastrophic outages. We used Terraform to simultaneously orchestrate isolated data planes in AWS and Azure, and developed an agnostic Python edge router to direct traffic based on tenant identity.

This model requires significant engineering maturity, but it guarantees that your infrastructure can scale infinitely horizontally while treating cloud providers as interchangeable utility commodities. As a next step, focus on automating the cross-cloud tenant migration process, allowing you to evacuate tenants from AWS to Azure in real-time if telemetry indicates a degradation in a specific provider's region.

Event-Driven Architecture on Azure vs AWS: Service Bus vs SNS/SQS

Cláudio Filipe Lima Rapôso — Tue, 21 Apr 2026 19:59:01 +0000

Your OrderService does six things when a customer clicks Place Order. It writes to the orders table, reserves inventory, charges the card, enqueues the shipping label, emails the receipt, and logs the analytics event. It does all of that inside one HTTP handler, in one transaction, on one box. When the payment gateway hiccups, the order fails. When the email provider rate-limits, the order fails. When inventory is slow, the order fails. The monolith tied six independent failure domains to one shared fate.

This article rebuilds that pipeline as an event-driven system on both Azure and AWS, and walks through where they genuinely differ - not where they superficially look the same. The reference scenario is e-commerce order processing with fan-out to Inventory, Payment, and Notification. Audience: intermediate-to-senior engineers who already read the vendor landing pages and want the parts those pages leave out.

The pattern before the products

Before naming any cloud service, fix the shape. What you want is publish/subscribe fan-out with durable per-consumer queues and per-consumer dead-letter queues. The producer emits one logical event - OrderPlaced - to a topic. The topic delivers a copy to one durable queue per consumer. Each consumer drains its own queue at its own pace, retries on its own schedule, and when it gives up, the message lands in its own DLQ - not a shared one.

That last part matters. A shared DLQ means a poisoned inventory message blocks the payment team's on-call from seeing their own poison. One queue per consumer, one DLQ per consumer, one retry budget per consumer. The blast radius of any single bad message is exactly one bounded context.

With the shape fixed, we can map it onto two clouds - one concern at a time.

Side by side, one concern at a time

Topic and subscription model

On AWS the topic and the queues are separate primitives. SNS publishes; SQS stores. You wire them together with a topic subscription and a queue policy. The queue holds your messages; the topic just fans them out. Two resource types per consumer.

On Azure Service Bus collapses that into one resource graph. A namespace contains a topic, and each consumer is a subscription on that topic. The subscription has a virtual queue behind it; you do not manage a separate queue resource. Fewer moving parts at the IaC layer, but less separation of concern - the topic and its subscribers share a lifecycle and a billing unit.

Queue semantics and DLQ

Both brokers are at-least-once. Consumers will see duplicates. No marketing slide changes that.

AWS pairs each SQS queue with an explicit DLQ via a redrive policy. maxReceiveCount is the threshold; the main queue holds the in-flight message until the consumer explicitly deletes it, controlled by visibility_timeout_seconds. That visibility timeout must exceed P99 handler latency, with margin. Set it too low and the broker redelivers while the first handler is still working - you get two concurrent handlers racing, and idempotency becomes load-bearing in a way you probably did not test.

Azure Service Bus bakes the DLQ into every subscription as $DeadLetterQueue. maxDeliveryCount plays the same role as maxReceiveCount. Service Bus also dead-letters on two classes of failure SQS does not know about: message TTL expiry and filter-evaluation exceptions. Those two extra DLQ triggers are real operational wins - expired or malformed messages do not vanish into metrics.

One common claim worth pushing back on: Service Bus gives exactly-once delivery. It does not. What it gives is duplicate detection within a bounded window (up to seven days) on a per-MessageId basis. That is a broker-side helper, not a semantic guarantee. Consumers must still be idempotent. Same story on SQS FIFO and its five-minute content-based dedup window.

Identity and data-plane auth

On AWS, consumers assume an IAM role from Lambda, ECS, or EKS. No access keys, no user credentials in config. The queue policy restricts senders to a specific topic ARN via an aws:SourceArn condition - without it, any SNS topic in your account can write to your queue. That is the classic confused-deputy footgun, and leaving the condition off is one of the most common rejection triggers in a real review.

On Azure, the equivalent of "no long-lived keys" is disableLocalAuth: true on the namespace, which kills SAS authentication entirely. All auth goes through AAD and Managed Identity. The right role is Service Bus Data Receiver scoped per subscription, not namespace-wide. Writers get Service Bus Data Sender on the topic. Scoping at the subscription level means a compromised notification consumer cannot read payment events - lateral movement is bounded by the RBAC scope.

Ordering

Both platforms can do ordering. Neither should do ordering by default.

On AWS, ordering means FIFO queues keyed by MessageGroupId. The cap is 300 messages/sec (3,000 with batching) per queue. That is a hard ceiling, not a soft throttle.

On Azure, ordering means SessionId on messages and requiresSession: true on the subscription. Order is preserved per session. Throughput is fine on Standard; partitioning on Premium pushes it higher. The cost is that session-pinning serialises a subscription - a slow consumer on one session stalls messages in that session until the lock clears.

If the domain does not require strict order, do not enable it. FIFO is a business decision, not an architectural default.

The trade-off matrix

This is the center of the article, not the closer. If you remember one thing, remember this table.

Dimension	AWS SNS + SQS	Azure Service Bus (Standard / Premium)
Primitive model	Topic (SNS) fans out to separate SQS queues - two resource types per consumer	Single namespace → topic → subscription - one resource graph
Cost model	Pay-per-request on both SNS publishes and SQS requests; no idle cost	Standard: pay-per-million operations + namespace hourly. Premium: fixed messaging units (predictable floor ≈ $670/MU/month at time of writing; verify current SKU pricing, it drifts)
Message ordering	Standard: none. FIFO: strict ordering by `MessageGroupId`, capped at 300 msgs/s (3,000 with batching)	Standard: ordering within a session (`SessionId`). Premium: same, higher throughput, partitioning supported
Delivery semantics	At-least-once. FIFO adds content-based dedup in a 5-minute window	At-least-once. PeekLock + duplicate detection up to 7 days. Broker-side helper; still needs idempotent consumers
Max message size	256 KB on both SNS and SQS. Workaround: claim-check via S3 + SQS Extended Client	Standard: 256 KB. Premium: 100 MB native
DLQ handling	Explicit SQS queue + redrive policy. `maxReceiveCount` threshold. Delivery-failure DLQ only	Implicit `$DeadLetterQueue` per subscription. `maxDeliveryCount` threshold. Also DLQs on TTL expiry and filter-eval errors
Filtering	SNS filter policies: JSON attribute match at subscription time	SQL filter and correlation filter per subscription - richer expression model
Ops surface	CloudWatch: `ApproximateNumberOfMessages`, `ApproximateAgeOfOldestMessage`. Alarm on DLQ depth > 0	Azure Monitor: `ActiveMessages`, `DeadletteredMessages`. Alarm on `DeadletteredMessages > 0`
Identity	IAM roles assumed by Lambda/ECS/EKS; SSE-KMS	AAD + Managed Identity; `disableLocalAuth=true` kills SAS
Network isolation	VPC Endpoints (Interface for SNS, Interface/Gateway for SQS)	Private Endpoint (Premium SKU for full VNet integration)
Throughput	SNS: millions of msgs/s. SQS standard: effectively unlimited. SQS FIFO: 300–3,000 msgs/s per queue	Standard: ~2,000 msgs/s per namespace as a working guideline. Premium: scales with messaging units (~1,000 msgs/s per MU)

One-line heuristic: If the workload demands >256 KB messages, strong ordering at high throughput, or VNet isolation with ordering, Service Bus Premium earns its cost. Otherwise - massive fan-out, idempotent consumers, per-request billing - SNS + SQS wins. Standard Service Bus is the baseline; Premium is an upgrade you justify, not a default.

The IaC - AWS

Production-grade Terraform. FinOps tags, SSE, redrive policies, and an aws:SourceArn condition on the queue policy. Keep all of it - each line carries a security or reliability property the cluster depends on.

terraform {
  required_version = ">= 1.6.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.40"
    }
  }
}

variable "project"        { type = string }
variable "environment"    { type = string }               # dev | stg | prd
variable "aws_region"     { type = string  default = "us-east-1" }
variable "consumers" {
  description = "Logical consumers that subscribe to the OrderPlaced topic."
  type        = set(string)
  default     = ["inventory", "payment", "notification"]
}
variable "max_receive_count" { type = number default = 5 } # redrive threshold

locals {
  name_prefix = "${var.project}-${var.environment}"
  tags = {
    Project     = var.project
    Environment = var.environment
    Workload    = "eda-orders"
    CostCenter  = "platform-events"
    ManagedBy   = "terraform"
  }
}

# --- Topic ----------------------------------------------------------------
resource "aws_sns_topic" "orders_placed" {
  name              = "${local.name_prefix}-orders-placed"
  kms_master_key_id = "alias/aws/sns"          # SSE at rest with AWS-managed CMK; swap to customer CMK for stricter tenants
  tags              = local.tags
}

# --- Queues + DLQs per consumer ------------------------------------------
resource "aws_sqs_queue" "dlq" {
  for_each                   = var.consumers
  name                       = "${local.name_prefix}-${each.key}-dlq"
  message_retention_seconds  = 1209600            # 14 days - max allowed, buys ops time
  kms_master_key_id          = "alias/aws/sqs"
  tags                       = merge(local.tags, { Role = "dlq", Consumer = each.key })
}

resource "aws_sqs_queue" "main" {
  for_each                   = var.consumers
  name                       = "${local.name_prefix}-${each.key}"
  visibility_timeout_seconds = 60                 # must exceed consumer max processing time
  message_retention_seconds  = 345600             # 4 days
  receive_wait_time_seconds  = 20                 # long polling - reduces empty-receive cost
  kms_master_key_id          = "alias/aws/sqs"
  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.dlq[each.key].arn
    maxReceiveCount     = var.max_receive_count
  })
  tags = merge(local.tags, { Role = "main", Consumer = each.key })
}

# --- Allow SNS to write to SQS -------------------------------------------
data "aws_iam_policy_document" "sns_to_sqs" {
  for_each = var.consumers
  statement {
    sid     = "AllowSNSDeliver"
    effect  = "Allow"
    actions = ["sqs:SendMessage"]
    principals {
      type        = "Service"
      identifiers = ["sns.amazonaws.com"]
    }
    resources = [aws_sqs_queue.main[each.key].arn]
    condition {
      test     = "ArnEquals"
      variable = "aws:SourceArn"
      values   = [aws_sns_topic.orders_placed.arn]
    }
  }
}

resource "aws_sqs_queue_policy" "main" {
  for_each  = var.consumers
  queue_url = aws_sqs_queue.main[each.key].id
  policy    = data.aws_iam_policy_document.sns_to_sqs[each.key].json
}

resource "aws_sns_topic_subscription" "consumer" {
  for_each             = var.consumers
  topic_arn            = aws_sns_topic.orders_placed.arn
  protocol             = "sqs"
  endpoint             = aws_sqs_queue.main[each.key].arn
  raw_message_delivery = true                     # consumers parse the raw event, not the SNS envelope
}

# --- Consumer IAM role template (least-privilege) ------------------------
data "aws_iam_policy_document" "consumer_assume" {
  statement {
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["lambda.amazonaws.com", "ecs-tasks.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "consumer" {
  for_each           = var.consumers
  name               = "${local.name_prefix}-${each.key}-consumer"
  assume_role_policy = data.aws_iam_policy_document.consumer_assume.json
  tags               = merge(local.tags, { Consumer = each.key })
}

data "aws_iam_policy_document" "consumer_sqs" {
  for_each = var.consumers
  statement {
    actions = [
      "sqs:ReceiveMessage",
      "sqs:DeleteMessage",
      "sqs:GetQueueAttributes",
      "sqs:ChangeMessageVisibility",
    ]
    resources = [aws_sqs_queue.main[each.key].arn]
  }
}

resource "aws_iam_role_policy" "consumer_sqs" {
  for_each = var.consumers
  role     = aws_iam_role.consumer[each.key].id
  policy   = data.aws_iam_policy_document.consumer_sqs[each.key].json
}

output "topic_arn" { value = aws_sns_topic.orders_placed.arn }
output "queues"    { value = { for k, q in aws_sqs_queue.main : k => q.arn } }
output "dlqs"      { value = { for k, q in aws_sqs_queue.dlq  : k => q.arn } }

The IaC - Azure

Same scenario, same tags, same maxDeliveryCount = 5. Note disableLocalAuth: true on the namespace and per-subscription RBAC at the bottom.

// Deployment scope: resourceGroup
targetScope = 'resourceGroup'

@description('Project short code, e.g. osecloud')
param project string

@allowed([ 'dev', 'stg', 'prd' ])
param environment string

@description('Azure region.')
param location string = resourceGroup().location

@description('Logical consumers that subscribe to the OrderPlaced topic.')
param consumers array = [ 'inventory', 'payment', 'notification' ]

@description('Consumer identity object IDs (managed identities that will receive Data Receiver role). Key must match a name in `consumers`.')
param consumerPrincipalIds object = {}

@description('Service Bus SKU. Use Premium when you need ordering at scale, VNet integration, or >1MB messages.')
@allowed([ 'Standard', 'Premium' ])
param skuName string = 'Standard'

var namePrefix = toLower('${project}-${environment}')
var tags = {
  project:     project
  environment: environment
  workload:    'eda-orders'
  costCenter:  'platform-events'
  managedBy:   'bicep'
}

// --- Namespace ------------------------------------------------------------
resource sbNamespace 'Microsoft.ServiceBus/namespaces@2022-10-01-preview' = {
  name:     '${namePrefix}-sb'
  location: location
  sku: {
    name: skuName
    tier: skuName
  }
  properties: {
    minimumTlsVersion: '1.2'
    publicNetworkAccess: 'Enabled' // set to 'Disabled' + private endpoint in prd
    disableLocalAuth: true         // force AAD/Managed Identity - no SAS keys
  }
  tags: tags
}

// --- Topic ----------------------------------------------------------------
resource topic 'Microsoft.ServiceBus/namespaces/topics@2022-10-01-preview' = {
  parent: sbNamespace
  name: 'orders-placed'
  properties: {
    defaultMessageTimeToLive: 'P14D'
    enableBatchedOperations: true
    supportOrdering: true          // preserves order within a session (partition) - only honoured with session-enabled subscriptions
  }
}

// --- Subscriptions + DLQ (DLQ is implicit per subscription) --------------
resource subs 'Microsoft.ServiceBus/namespaces/topics/subscriptions@2022-10-01-preview' = [for name in consumers: {
  parent: topic
  name:   '${name}-sub'
  properties: {
    deadLetteringOnMessageExpiration:    true
    deadLetteringOnFilterEvaluationExceptions: true
    maxDeliveryCount: 5             // redrive threshold → moves to $DeadLetterQueue
    lockDuration:     'PT1M'        // matches visibility-timeout in AWS terms
    defaultMessageTimeToLive: 'P4D'
    requiresSession: false          // set true for FIFO-per-session guarantees
  }
}]

// --- RBAC: Azure Service Bus Data Receiver on each subscription ----------
var dataReceiverRoleId = '4f6d3b9b-027b-4f4c-9142-0e5a2a2247e0' // Service Bus Data Receiver

resource rbacReceiver 'Microsoft.Authorization/roleAssignments@2022-04-01' = [for (name, i) in consumers: if (contains(consumerPrincipalIds, name)) {
  name:  guid(subs[i].id, consumerPrincipalIds[name], dataReceiverRoleId)
  scope: subs[i]
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', dataReceiverRoleId)
    principalId:      consumerPrincipalIds[name]
    principalType:    'ServicePrincipal'
  }
}]

output namespaceId       string = sbNamespace.id
output topicId           string = topic.id
output subscriptionNames array  = [for (name, i) in consumers: subs[i].name]

One caveat on the API version: 2022-10-01-preview is still labelled preview at the time of writing. If your platform team forbids preview API versions in production, pin to the latest stable GA release and re-test disableLocalAuth - its behaviour has shifted across API versions.

Seven architectural constraints

Treat these as acceptance criteria for any EDA pipeline you ship on either cloud. They are a punch list, not a wish list.

At-least-once is the default on both sides. Exactly-once is a consumer property - idempotent handlers plus a dedup store - not a broker guarantee. Broker-side windows (SQS FIFO 5 min, Service Bus duplicate detection up to 7 days) narrow the problem; they do not eliminate it.
Visibility timeout and lock duration must exceed P99 handler latency. If the broker redelivers while the first handler is still working, you double-process. Measure P99 under load, add headroom, and alert when handler duration approaches the timeout.
Ordering is a bet you pay for. FIFO caps AWS throughput at 300–3,000 msgs/s; sessions serialise Azure subscriptions. Turn it on only when the domain demands ordering - never as a safety blanket.
DLQs are not a graveyard. They need alerts (DLQ depth > 0 pages the on-call) and a documented replay procedure - SQS redrive or Service Bus $DeadLetterQueue receive-and-resubmit. A DLQ without a replay runbook is a silent leak.
Large messages are an anti-pattern. >256 KB on AWS implies claim-check via S3. Premium Service Bus supports 100 MB, but transport cost and consumer memory pressure still argue for claim-check at that size.
Tag every resource with project, environment, workload, costCenter, managedBy. Without those tags, FinOps cannot attribute spend and the platform team cannot enforce lifecycle policies. The snippets above carry the full set; do not strip them.
No SAS keys, no IAM user keys. Managed Identity on Azure, IAM roles on AWS. disableLocalAuth: true on the Service Bus namespace, aws:SourceArn condition on every SQS queue policy. Anything else is a long-lived credential waiting to leak.

The choice between SNS/SQS and Service Bus is rarely binary. Start on Standard Service Bus or SNS + SQS. Move to Premium or FIFO only when a constraint above - size, ordering, isolation - forces you there.

Practical Guide: Building a Cell-Based Architecture on Azure with Terraform and Python

Cláudio Filipe Lima Rapôso — Tue, 21 Apr 2026 15:15:00 +0000

1. Introduction

As cloud applications scale to serve global audiences, relying on a single centralized infrastructure stack introduces critical vulnerabilities. A localized failure or a noisy neighbor can trigger a systemic outage. Cell-Based Architecture mitigates this by partitioning the system into isolated, identical, and self-contained units called "cells." By routing specific tenants or users to dedicated cells, you constrain the blast radius of any degradation strictly to that cell, preserving the availability of the rest of the system.

By the end of this tutorial, you will be able to design and provision a cellular architecture on Microsoft Azure. We will utilize Azure Front Door as the global ingress, Azure Functions (Python) for dynamic traffic routing and compute, and Azure Cosmos DB for isolated state management. Mastering this pattern on Azure not only hardens your current workloads but also reinforces foundational multicloud principles, as the concepts of decoupled routing and state isolation are directly transferable across different cloud providers in a unified enterprise landscape.

2. Prerequisites

To execute the configurations and code in this tutorial, ensure you have the following tools and access levels:

An active Microsoft Azure subscription with Owner or Contributor permissions to create Resource Groups, Cosmos DB accounts, Azure Functions, and Azure Front Door.
Terraform CLI (version 1.0 or higher) installed locally for provisioning the Infrastructure as Code (IaC).
Python (version 3.9 or higher) installed locally, along with the Azure Functions Core Tools for local development and packaging.
Azure CLI installed and authenticated (az login) on your local environment.
Fundamental understanding of partitioning concepts and Terraform HCL syntax.

3. Step-by-Step

Before diving into the infrastructure code, let's visualize the execution flow. The sequence diagram below details how a global request is securely intercepted, evaluated, and forwarded to a strictly isolated cellular stack within Azure.

3.1 Defining the Cell Blueprint (Terraform Module)

What to do: Create a reusable Terraform module representing a single, isolated "Cell." This includes a dedicated Storage Account, Application Service Plan, Azure Function (Worker), and a Cosmos DB database.

Why do it: The primary rule of cellular architecture is absolute consistency across environments. By encapsulating the infrastructure in a Terraform module, you ensure that every generated cell is an exact replica, preventing configuration drift and simplifying horizontal scaling.

Example:
Create a directory named modules/cell and add a main.tf file.

# modules/cell/main.tf
variable "location" { type = string }
variable "resource_group_name" { type = string }
variable "cell_id" { type = string }

resource "azurerm_cosmosdb_account" "cell_db" {
  name                = "cosmos-cell-${var.cell_id}"
  location            = var.location
  resource_group_name = var.resource_group_name
  offer_type          = "Standard"
  kind                = "GlobalDocumentDB"

  consistency_policy {
    consistency_level = "Session"
  }

  geo_location {
    location          = var.location
    failover_priority = 0
  }
}

resource "azurerm_cosmosdb_sql_database" "cell_sqldb" {
  name                = "app-state"
  resource_group_name = var.resource_group_name
  account_name        = azurerm_cosmosdb_account.cell_db.name
}

resource "azurerm_storage_account" "cell_storage" {
  name                     = "stcell${var.cell_id}"
  resource_group_name      = var.resource_group_name
  location                 = var.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_service_plan" "cell_plan" {
  name                = "plan-cell-${var.cell_id}"
  location            = var.location
  resource_group_name = var.resource_group_name
  os_type             = "Linux"
  sku_name            = "Y1" # Consumption plan
}

resource "azurerm_linux_function_app" "cell_worker" {
  name                       = "func-worker-${var.cell_id}"
  location                   = var.location
  resource_group_name        = var.resource_group_name
  service_plan_id            = azurerm_service_plan.cell_plan.id
  storage_account_name       = azurerm_storage_account.cell_storage.name
  storage_account_access_key = azurerm_storage_account.cell_storage.primary_access_key

  site_config {
    application_stack {
      python_version = "3.11"
    }
  }

  app_settings = {
    "CELL_ID"             = var.cell_id
    "COSMOS_DB_ENDPOINT"  = azurerm_cosmosdb_account.cell_db.endpoint
  }
}

output "function_default_hostname" {
  value = azurerm_linux_function_app.cell_worker.default_hostname
}

3.2 Stamping Out Multiple Cells

What to do: In your root Terraform configuration, define the base resource group and iterate over a collection of identifiers to deploy multiple cells simultaneously.

Why do it: This translates the theoretical module into physical, isolated environments. Using a for_each loop allows you to effortlessly scale from two cells to fifty cells simply by updating a local variable, abstracting the complexity of managing parallel infrastructures.

Example:
In your root directory, create main.tf.

# main.tf
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "rg" {
  name     = "rg-cellular-architecture"
  location = "East US"
}

locals {
  cells = ["alpha", "beta"]
}

module "isolated_cells" {
  source   = "./modules/cell"
  for_each = toset(local.cells)

  cell_id             = each.key
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

3.3 Developing the Cell Router in Python

What to do: Write the Azure Function code in Python that will act as the global ingress router. It must inspect incoming HTTP requests, determine the appropriate tenant mapping, and proxy the request to the correct cell.

Why do it: The router abstracts the internal topology from the client. Applications interact with a single API endpoint, oblivious to the fact that their request is being routed to cell-alpha or cell-beta. This dynamic mapping is what allows you to perform live migrations of tenants between cells to balance load without downtime.

Example:
Create the Python code for your router function (__init__.py inside your Azure Function folder).

import logging
import json
import os
import urllib.request
import azure.functions as func

# In production, fetch this from Cosmos DB (Tenant Registry)
CELL_ENDPOINTS = {
    "alpha": os.environ.get("CELL_ALPHA_URL", "https://func-worker-alpha.azurewebsites.net"),
    "beta": os.environ.get("CELL_BETA_URL", "https://func-worker-beta.azurewebsites.net")
}

def get_target_cell(tenant_id: str) -> str:
    # Mocking a Cosmos DB registry lookup
    # A real implementation would query the global metadata database
    if tenant_id.startswith("A"):
        return "alpha"
    return "beta"

def main(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('Global Router processing a request.')

    try:
        req_body = req.get_json()
        tenant_id = req_body.get('tenant_id')

        if not tenant_id:
            return func.HttpResponse(
                "Missing partition key: tenant_id", 
                status_code=400
            )

        target_cell = get_target_cell(tenant_id)
        target_url = f"{CELL_ENDPOINTS[target_cell]}/api/process"

        # Proxy the request to the isolated cell
        data = json.dumps(req_body).encode('utf-8')
        proxy_req = urllib.request.Request(
            target_url, 
            data=data,
            headers={'Content-Type': 'application/json'}
        )

        with urllib.request.urlopen(proxy_req) as response:
            cell_response = response.read().decode('utf-8')

        return func.HttpResponse(
            json.dumps({
                "status": "success",
                "x_routed_to": target_cell,
                "data": json.loads(cell_response)
            }),
            mimetype="application/json",
            status_code=200
        )

    except Exception as e:
        logging.error(f"Routing error: {str(e)}")
        return func.HttpResponse("Internal Server Error", status_code=500)

3.4 Provisioning the Global Routing Layer

What to do: Deploy the central routing Azure Function and configure an Azure Front Door profile to sit in front of it.

Why do it: Azure Front Door acts as a secure, globally distributed entry point. It absorbs DDoS attacks at the edge, provides WAF capabilities, and ensures that the Global Router Function is protected from direct, unauthenticated internet exposure.

Example:
Append the routing infrastructure to your root main.tf.

# Shared storage for the Global Router
resource "azurerm_storage_account" "router_storage" {
  name                     = "stglobalrouter"
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_service_plan" "router_plan" {
  name                = "plan-global-router"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  os_type             = "Linux"
  sku_name            = "Y1"
}

resource "azurerm_linux_function_app" "global_router" {
  name                       = "func-global-router-gateway"
  location                   = azurerm_resource_group.rg.location
  resource_group_name        = azurerm_resource_group.rg.name
  service_plan_id            = azurerm_service_plan.router_plan.id
  storage_account_name       = azurerm_storage_account.router_storage.name
  storage_account_access_key = azurerm_storage_account.router_storage.primary_access_key

  site_config {
    application_stack {
      python_version = "3.11"
    }
  }

  app_settings = {
    "CELL_ALPHA_URL" = "https://${module.isolated_cells["alpha"].function_default_hostname}"
    "CELL_BETA_URL"  = "https://${module.isolated_cells["beta"].function_default_hostname}"
  }
}

Run terraform init, terraform plan, and terraform apply to deploy the entire multi-cell architecture.

4. Common Troubleshooting

Transitioning to a cellular architecture requires a shift in how you manage state and traffic. Here are common issues you may encounter:

Cosmos DB Throttling (HTTP 429) in a Specific Cell:
- Problem: One cell begins rejecting requests, while others operate normally. This usually indicates a "noisy neighbor" – a tenant whose workload has suddenly spiked, exhausting the Request Units (RUs) provisioned for that specific cell's database.
- Solution: Verify the metrics in Azure Monitor. If a tenant has outgrown the shared cell, you must execute a live migration. Update the Global Tenant Registry (Metadata DB) to point that specific tenant_id to a newly provisioned, dedicated cell, seamlessly redirecting their traffic.
Latency Overhead at the Routing Layer:
- Problem: Requests take significantly longer because they must pass through Front Door, the Router Function, and finally the Cell Function.
- Solution: The router logic must be aggressively optimized. Implement caching at the Global Router level using Azure Cache for Redis so the function doesn't need to query Cosmos DB for the tenant mapping on every single request.
Cold Starts in Azure Functions:
- Problem: The first request to a specific cell takes several seconds to execute.
- Solution: Since we used the Consumption Plan (Y1) for cost-effectiveness in this tutorial, cold starts are expected. For production workloads, switch the Application Service Plan to Premium (EP1 or higher) to keep instances pre-warmed, ensuring consistent low-latency responses.

5. Conclusion

Building a Cell-Based Architecture on Azure transforms monolithic vulnerabilities into contained, manageable units. By utilizing Terraform, we established a reproducible baseline for isolated environments, and implemented a Python routing layer to dynamically proxy traffic.

This decoupling ensures that massive traffic spikes or bad deployments are restricted to single domains. As you mature this architecture, focus on automating the "Tenant Migration" process—moving live data between Cosmos DB instances without downtime—and standardizing your Terraform modules to ensure this pattern can be rapidly adopted across multiple cloud environments.

Practical Guide: Building a Cell-Based Architecture on AWS with Terraform and Python

Cláudio Filipe Lima Rapôso — Tue, 21 Apr 2026 15:11:00 +0000

1. Introduction

In the cloud-native era, systems often reach a point where scaling a single massive architecture introduces unacceptable risks. A failure in a centralized component can result in a global outage, affecting all users simultaneously. Cell-Based Architecture solves this by dividing the system into multiple isolated, standalone, and identical instances called "cells." By placing users (or tenants) into specific cells, you drastically reduce the blast radius of any failure.

While this tutorial focuses on an AWS implementation, designing cellular strategies is a cornerstone of robust multicloud engineering. The principles of isolating state and routing traffic based on partition keys apply seamlessly across different providers, such as Microsoft Azure, ensuring your landing zones maintain high availability regardless of the underlying cloud.

By the end of this tutorial, you will understand how to provision a cellular infrastructure on AWS using Terraform. We will create a blueprint for a "cell," stamp out multiple instances of it, and build a Cell Router layer in Python to direct traffic to the correct isolated environment.

2. Prerequisites

To successfully implement this architectural pattern, you will need:

An active Amazon Web Services (AWS) account with administrative privileges.
Terraform installed locally (version 1.0 or higher) for Infrastructure as Code.
Python (version 3.9 or higher) to write the routing logic.
AWS credentials configured in your environment.
A foundational understanding of architectural decoupling and partition logic.

3. Step-by-Step

A Cell-Based Architecture introduces a "Thin Routing Layer" in front of your core infrastructure. The diagram below illustrates how an incoming request is evaluated and forwarded to a strictly isolated cellular stack.

3.1 Defining the Cell Blueprint (Terraform Module)

What to do: Create a reusable Terraform module that defines exactly what a single "Cell" looks like.
Why do it: The core tenet of cellular architecture is that every cell is identical. By using a Terraform module, you ensure that any updates to the infrastructure are applied uniformly across all isolated cells, preventing configuration drift.

Example:
Create a folder named modules/cell and add a main.tf file inside it. This blueprint contains an API Gateway, a Lambda function, and an isolated DynamoDB table.

# modules/cell/main.tf
variable "cell_id" {
  type        = string
  description = "Unique identifier for the cell (e.g., cell-1)"
}

resource "aws_dynamodb_table" "cell_state" {
  name           = "app-state-${var.cell_id}"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "id"

  attribute {
    name = "id"
    type = "S"
  }
}

resource "aws_lambda_function" "cell_compute" {
  filename      = "cell_worker.zip"
  function_name = "worker-${var.cell_id}"
  role          = aws_iam_role.cell_role.arn
  handler       = "worker.handler"
  runtime       = "python3.11"

  environment {
    variables = {
      CELL_ID    = var.cell_id
      TABLE_NAME = aws_dynamodb_table.cell_state.name
    }
  }
}

# (IAM Roles and API Gateway configurations for the cell would follow here)

3.2 Stamping Out Multiple Cells

What to do: In your root main.tf, iterate over a list of cell identifiers to provision multiple identical, isolated environments.
Why do it: This allows you to scale horizontally by adding new completely independent infrastructure stacks rather than increasing the size of a monolithic database or compute cluster.

Example:
In your root directory, create a main.tf to invoke the module.

# main.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

locals {
  cells = ["cell-alpha", "cell-beta"]
}

module "isolated_cells" {
  source   = "./modules/cell"
  for_each = toset(local.cells)

  cell_id = each.key
}

3.3 Developing the Cell Router in Python

What to do: Write a Python function that acts as the ingress routing layer, determining which cell should handle a specific request based on a partition key.
Why do it: Clients should not need to know which cell they belong to. The router abstracts this complexity, allowing you to migrate tenants between cells behind the scenes without breaking client integrations.

Example:
Create a router.py file. This logic intercepts the request, hashes the partition key (e.g., tenant_id), and routes it.

import json
import hashlib
import urllib.request

# In a real environment, this mapping could be retrieved from a highly available edge key-value store.
CELL_ENDPOINTS = {
    "cell-alpha": "https://alpha.execute-api.us-east-1.amazonaws.com/prod",
    "cell-beta": "https://beta.execute-api.us-east-1.amazonaws.com/prod"
}

def get_target_cell(partition_key: str) -> str:
    """Consistently hashes the partition key to a specific cell."""
    hash_val = int(hashlib.md5(partition_key.encode('utf-8')).hexdigest(), 16)

    # Simple modulo distribution
    if hash_val % 2 == 0:
        return "cell-alpha"
    return "cell-beta"

def lambda_handler(event, context):
    try:
        body = json.loads(event.get('body', '{}'))
        tenant_id = body.get('tenant_id')

        if not tenant_id:
            return {"statusCode": 400, "body": "Missing partition key: tenant_id"}

        target_cell = get_target_cell(tenant_id)
        target_endpoint = CELL_ENDPOINTS[target_cell]

        # Forwarding the request to the isolated cell (Simplified for demonstration)
        req = urllib.request.Request(
            f"{target_endpoint}/process", 
            data=event.get('body').encode('utf-8'),
            headers={'Content-Type': 'application/json'}
        )

        with urllib.request.urlopen(req) as response:
            cell_response = response.read()

        return {
            "statusCode": 200,
            "body": json.dumps({
                "routed_to": target_cell,
                "cell_response": json.loads(cell_response)
            })
        }

    except Exception as e:
        return {"statusCode": 500, "body": str(e)}

3.4 Provisioning the Routing Layer

What to do: Add the routing layer to your root Terraform configuration to expose a single unified endpoint to your users.
Why do it: This centralizes ingress control. All external traffic hits the router, which then proxies the data over the AWS internal backbone to the respective cells, ensuring strict access control at the boundary.

Example:
Add this to your root main.tf:

data "archive_file" "router_zip" {
  type        = "zip"
  source_file = "router.py"
  output_path = "router.zip"
}

resource "aws_lambda_function" "cell_router" {
  filename      = data.archive_file.router_zip.output_path
  function_name = "GlobalCellRouter"
  role          = aws_iam_role.router_role.arn # (Assume basic execution role is created)
  handler       = "router.lambda_handler"
  runtime       = "python3.11"
}

resource "aws_lambda_function_url" "router_url" {
  function_name      = aws_lambda_function.cell_router.function_name
  authorization_type = "NONE"
}

output "global_entrypoint" {
  value       = aws_lambda_function_url.router_url.function_url
  description = "The single URL clients interact with."
}

4. Common Troubleshooting

Deploying cellular architectures shifts the complexity from infrastructure scaling to traffic routing and state management. Be prepared to handle these common challenges:

Partition Key Skew (Noisy Neighbors):
- Problem: One cell becomes overloaded while others are idle because a specific tenant_id generates 80% of the traffic.
- Solution: Monitor cell metrics closely. If a tenant outgrows a shared cell, you must implement a "tenant migration" process to move their data to an exclusive, single-tenant cell, updating the router's mapping logic accordingly.
Cross-Cell Data Aggregation:
- Problem: You need to generate a global report, but the data is split across multiple isolated DynamoDB tables.
- Solution: Do not query cells directly for global data. Implement an asynchronous data lake strategy where each cell streams its state changes (e.g., via DynamoDB Streams and Kinesis) to a central analytical data store.
Router Layer Bottlenecks:
- Problem: The Cell Router itself goes down, causing a global outage—exactly what cellular architecture tries to prevent.
- Solution: The routing layer must be incredibly thin and rely on highly resilient, geographically distributed edge services (like Amazon Route 53 or CloudFront/Lambda@Edge) rather than a single compute instance.

5. Conclusion

By implementing a Cell-Based Architecture, you establish definitive fault-isolation boundaries. We utilized Terraform to define a repeatable cell blueprint and created a thin Python routing layer to direct traffic dynamically.

This approach minimizes the blast radius of localized failures, making your systems inherently more resilient. As you expand on this concept, consider how this decoupled routing strategy translates across multicloud landscapes, allowing you to seamlessly route traffic between an AWS cell and an Azure cell based on performance, cost, or regulatory requirements.

Practical Guide: Building an Event-Driven Infrastructure on Microsoft Azure with Terraform and Python

Cláudio Filipe Lima Rapôso — Sun, 19 Apr 2026 13:57:33 +0000

1. Introduction

Event-driven architectures decouple system components, replacing direct synchronous communication with a highly scalable publish-subscribe model. By the end of this tutorial, you will be able to provision a complete event-based infrastructure on Microsoft Azure. This setup utilizes Azure Event Grid as the central event routing backbone, Azure Service Bus for reliable message queuing, and Azure Functions for serverless computational processing.

Mastering this topology is a structural requirement for modern software design. Isolating producers from consumers ensures that localized failures do not cascade through the system, enabling independent scaling of microservices. Furthermore, translating these concepts across different cloud providers strengthens a robust multicloud strategy, allowing you to map architectural patterns (like Event Bus -> Queue -> Serverless Compute) seamlessly into an Azure-based landing zone.

2. Prerequisites

To execute the configurations proposed in this guide, ensure you have the following prerequisites established:

An active Microsoft Azure account with permissions to create Resource Groups, Event Grid topics, Service Bus namespaces, and Function Apps.
Terraform installed locally (version 1.0 or higher) for provisioning the Infrastructure as Code (IaC).
Python (version 3.9 or higher) installed locally for developing the function logic.
The Azure CLI (az) installed and authenticated in your local environment.
Familiarity with terminal navigation and Terraform HCL syntax.

3. Step-by-Step

Before diving into the code, it is critical to visualize the event lifecycle. The sequence diagram below maps the flow of information across the provisioned Azure services.

3.1 Configuring the Provider and Resource Group

What to do: Define the Azure Resource Manager (azurerm) provider in Terraform and create a foundational Resource Group to logically group all infrastructure assets.

Why do it: Terraform requires provider definitions to authenticate and interact with the specific cloud API. The Resource Group is a mandatory Azure construct that controls the lifecycle and access management of the resources it contains.

Example:
Create a file named main.tf and add the following configuration:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "rg" {
  name     = "rg-event-driven-architecture"
  location = "East US"
}

3.2 Creating the Event Grid Topic

What to do: Provision a Custom Topic in Azure Event Grid.

Why do it: A Custom Topic serves as the dedicated endpoint where your applications publish business events. Isolating business events in a custom topic prevents mixing application logic with underlying Azure infrastructure events.

Example:
Append the following block to your main.tf:

resource "azurerm_eventgrid_topic" "custom_topic" {
  name                = "app-domain-events-topic"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

3.3 Provisioning the Service Bus Namespace and Queue

What to do: Create a Service Bus Namespace and a specific Queue within it to absorb incoming events.

Why do it: While Event Grid can push directly to an Azure Function, routing through a Service Bus Queue introduces a critical buffer. This ensures high availability, message durability, and prevents overwhelming the downstream compute service during traffic spikes.

Example:
Add the Service Bus configurations:

resource "azurerm_servicebus_namespace" "sb_namespace" {
  name                = "sb-event-driven-demo"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  sku                 = "Standard"
}

resource "azurerm_servicebus_queue" "event_queue" {
  name         = "event-processing-queue"
  namespace_id = azurerm_servicebus_namespace.sb_namespace.id
}

3.4 Developing the Azure Function in Python

What to do: Write the Python code using the Azure Functions v2 programming model to process messages arriving in the Service Bus Queue.

Why do it: The function represents the business logic reacting to the event. The v2 model utilizes decorators, providing a clean, concise way to define triggers and bindings directly in the code, automatically handling message deserialization.

Example:
Create a file named function_app.py in your project directory:

import logging
import json
import azure.functions as func

# Initialize the Function App
app = func.FunctionApp()

@app.service_bus_queue_trigger(
    arg_name="msg", 
    queue_name="event-processing-queue",
    connection="ServiceBusConnection"
)
def process_domain_event(msg: func.ServiceBusMessage):
    logger = logging.getLogger()
    logger.info("Initiating Service Bus event processing.")

    try:
        # Decode and load the message body
        msg_body = msg.get_body().decode('utf-8')
        event_payload = json.loads(msg_body)

        logger.info(f"Complete event payload: {json.dumps(event_payload, indent=2)}")

        # Event Grid schema typically encapsulates data in a 'data' field
        data = event_payload.get('data', {})
        order_id = data.get('order_id')

        logger.info(f"Successfully processed business operation for order: {order_id}")

    except json.JSONDecodeError:
        logger.error("Failed to decode message payload as JSON.")
    except Exception as e:
        logger.error(f"Unexpected error during processing: {str(e)}")

3.5 Provisioning the Compute Infrastructure for the Function

What to do: Define the Storage Account, Service Plan (Consumption), and the Linux Function App via Terraform, injecting the necessary connection strings as environment variables.

Why do it: Azure Functions require a backing storage account for state management and an execution plan to define scale and pricing. Injecting ServiceBusConnection securely links the compute tier to the messaging tier.

Example:
Add the compute resources to your main.tf:

resource "azurerm_storage_account" "sa" {
  name                     = "saeventdrivendemo123" # Must be globally unique
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_service_plan" "asp" {
  name                = "asp-event-driven"
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  os_type             = "Linux"
  sku_name            = "Y1" # Serverless Consumption Plan
}

resource "azurerm_linux_function_app" "function_app" {
  name                       = "func-order-processor-app"
  resource_group_name        = azurerm_resource_group.rg.name
  location                   = azurerm_resource_group.rg.location
  service_plan_id            = azurerm_service_plan.asp.id
  storage_account_name       = azurerm_storage_account.sa.name
  storage_account_access_key = azurerm_storage_account.sa.primary_access_key

  site_config {
    application_stack {
      python_version = "3.11"
    }
  }

  app_settings = {
    "FUNCTIONS_WORKER_RUNTIME" = "python"
    "ServiceBusConnection"     = azurerm_servicebus_namespace.sb_namespace.default_primary_connection_string
  }
}

3.6 Creating the Event Grid Subscription (Routing Rule)

What to do: Configure an Event Subscription that filters events arriving at the Custom Topic and routes them to the Service Bus Queue.

Why do it: Advanced filtering ensures that only relevant events reach the compute tier, preventing unnecessary executions and lowering costs. This acts as the intelligent router in the architecture.

Example:
Complete the main.tf file with the routing subscription:

resource "azurerm_eventgrid_event_subscription" "queue_subscription" {
  name  = "route-order-created"
  scope = azurerm_eventgrid_topic.custom_topic.id

  service_bus_queue_endpoint_id = azurerm_servicebus_queue.event_queue.id

  advanced_filter {
    string_in {
      key    = "data.detail-type"
      values = ["OrderCreated"]
    }
  }
}

To deploy the infrastructure, run terraform init, terraform plan, and terraform apply. Note that while Terraform provisions the infrastructure, the actual deployment of the Python code is typically handled via Azure Functions Core Tools (func azure functionapp publish func-order-processor-app) or a CI/CD pipeline like GitHub Actions.

4. Common Troubleshooting

Deploying distributed systems can introduce integration challenges. Here are the most common issues and how to resolve them:

Service Bus Connection String Missing or Invalid:
Issue: The Azure Function fails to trigger, and logs show binding errors.
Solution: Verify the Application Settings in the Azure Portal for the Function App. Ensure ServiceBusConnection exactly matches the primary connection string of the Service Bus Namespace and is spelled correctly in the app.service_bus_queue_trigger decorator.
Event Grid Schema Mismatch:
Issue: Events are successfully published to the topic but never arrive in the Service Bus Queue.
Solution: Inspect the payload structure. Azure Event Grid requires a specific schema (id, subject, data, eventType, etc.). If you are filtering by data.detail-type in Terraform, ensure your published JSON explicitly contains a data object with a detail-type key matching "OrderCreated".
Storage Account Naming Conflicts:
Issue: Terraform fails during the terraform apply phase when creating the azurerm_storage_account.
Solution: Storage account names in Azure must be globally unique across all Azure customers, purely lowercase, and between 3 to 24 characters. Adjust the name attribute in the Terraform block to a highly unique string.

5. Conclusion

This tutorial established a resilient, decoupled architecture native to Microsoft Azure. By utilizing Terraform, we provisioned Event Grid for intelligent event routing, Service Bus for robust message queuing, and Azure Functions for scalable compute.

Implementing these patterns provides a clear parallel to other cloud ecosystems, reinforcing a strong foundation for designing cellular architectures and multicloud strategies. As a next step, explore implementing Dead-Letter Queues (DLQ) within the Service Bus to handle poison messages systematically, ensuring your distributed application remains robust even when faced with unprocessable data.

Practical Guide: Building an Event-Driven Infrastructure on AWS with Terraform and Python

Cláudio Filipe Lima Rapôso — Sun, 19 Apr 2026 13:52:58 +0000

1. Introduction

Event-driven architectures transform the way systems communicate by replacing direct synchronous calls with a highly decoupled publish-subscribe model. By the end of this tutorial, you will be able to provision a complete event-based infrastructure on AWS, using Amazon EventBridge as the central router, Amazon SQS for queuing, and AWS Lambda for computational processing.

This approach is fundamental for creating scalable and resilient systems. Decoupling ensures that a failure in one component does not take down the entire application, and it allows different parts of the system to scale independently. Although the technical focus here is AWS, mastering event routing and asynchronous processing is a core structural skill for strategies in multicloud environments, where similar architectural patterns are applied using corresponding services from each provider within a unified landing zone.

2. Prerequisites

To follow this tutorial and execute the proposed configurations, you need the following resources and prior knowledge:

An active Amazon Web Services (AWS) account with administrative permissions to create IAM, Lambda, SQS, and EventBridge resources.
Terraform installed on your local machine (version 1.0 or higher) for provisioning the Infrastructure as Code (IaC).
Python (version 3.9 or higher) installed locally to package the Lambda function code.
AWS credentials configured in your local environment (via AWS CLI or environment variables).
Basic knowledge of terminal navigation and Terraform HCL syntax.

3. Step-by-Step

Before writing the code, it is important to visualize the event lifecycle in our infrastructure. The sequence diagram below illustrates the flow of information between the provisioned services.

3.1 Configuring the Provider and Main File

What to do: Create the initial Terraform configuration file to define AWS as the cloud provider and establish the deployment region.

Why do it: Terraform needs to know which cloud API it will interact with and the default region to allocate resources. This centralizes the basic configuration and prepares the infrastructure state.

Example:
Create a file named main.tf and add the following block:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

3.2 Creating the Event Bus (EventBridge)

What to do: Provision a customized event bus in Amazon EventBridge.

Why do it: Although AWS provides a default bus, creating a custom bus for applications is an excellent domain isolation practice. This prevents mixing AWS infrastructure events with your application's business events.

Example:
Add to your main.tf file:

resource "aws_cloudwatch_event_bus" "custom_bus" {
  name = "app-domain-events"
}

3.3 Creating the SQS Queue for Load Absorption

What to do: Create a queue in Amazon SQS and configure the access policy to allow EventBridge to send messages to it.

Why do it: Sending events directly from EventBridge to Lambda can cause data loss in case of failures or traffic spikes. The SQS queue acts as a buffer, ensuring message delivery and allowing reprocessing in case of temporary errors.

Example:
Add the queue configurations and its respective policy:

resource "aws_sqs_queue" "event_queue" {
  name = "event-processing-queue"
}

resource "aws_sqs_queue_policy" "event_queue_policy" {
  queue_url = aws_sqs_queue.event_queue.id
  policy    = data.aws_iam_policy_document.sqs_policy.json
}

data "aws_iam_policy_document" "sqs_policy" {
  statement {
    effect    = "Allow"
    actions   = ["sqs:SendMessage"]
    resources = [aws_sqs_queue.event_queue.arn]

    principals {
      type        = "Service"
      identifiers = ["events.amazonaws.com"]
    }

    condition {
      test     = "ArnEquals"
      variable = "aws:SourceArn"
      values   = [aws_cloudwatch_event_rule.event_rule.arn]
    }
  }
}

3.4 Developing the Lambda Function in Python

What to do: Write the Python source code that will be executed when an event arrives in the queue.

Why do it: The Python code represents the business or computational logic that reacts to the event. In this example, we will iterate over the SQS queue records and log the details for visual validation of the architecture's functionality.

Example:
Create a file named processor.py in the same directory:

import json
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    logger.info("Starting processing of SQS event batch.")

    for record in event.get('Records', []):
        body_string = record.get('body', '{}')

        try:
            event_detail = json.loads(body_string)
            logger.info(f"Received event detail: {json.dumps(event_detail, indent=2)}")

            # Extracting the payload from EventBridge
            detail = event_detail.get('detail', {})
            order_id = detail.get('order_id')

            logger.info(f"Successfully processed order: {order_id}")

        except json.JSONDecodeError:
            logger.error("Error decoding message body as JSON.")

    return {
        'statusCode': 200,
        'body': json.dumps('Processing completed successfully')
    }

3.5 Provisioning Lambda with Terraform and Connecting to the Queue

What to do: Create the ZIP package of the Python code, define the Lambda function in Terraform, create the execution permission (IAM Role), and map the SQS queue as the Lambda event source.

Why do it: The infrastructure needs to allocate the code in AWS and provide the exact permissions so the Lambda can read messages from the queue and write logs to CloudWatch, following the principle of least privilege.

Example:
Add the following code to your main.tf:

data "archive_file" "lambda_zip" {
  type        = "zip"
  source_file = "processor.py"
  output_path = "processor.zip"
}

resource "aws_iam_role" "lambda_exec_role" {
  name = "lambda_sqs_execution_role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "lambda.amazonaws.com"
      }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_basic_execution" {
  role       = aws_iam_role.lambda_exec_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

resource "aws_iam_role_policy_attachment" "lambda_sqs_execution" {
  role       = aws_iam_role.lambda_exec_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaSQSQueueExecutionRole"
}

resource "aws_lambda_function" "event_processor" {
  filename         = data.archive_file.lambda_zip.output_path
  function_name    = "OrderEventProcessor"
  role             = aws_iam_role.lambda_exec_role.arn
  handler          = "processor.lambda_handler"
  source_code_hash = data.archive_file.lambda_zip.output_file_base64sha256
  runtime          = "python3.11"
}

resource "aws_lambda_event_source_mapping" "sqs_trigger" {
  event_source_arn = aws_sqs_queue.event_queue.arn
  function_name    = aws_lambda_function.event_processor.arn
  batch_size       = 10
}

3.6 Creating the Routing Rule in EventBridge

What to do: Configure a rule that filters specific events published on the bus and directs them to the SQS queue.

Why do it: The bus can receive thousands of different events. Rules ensure that the target system (your SQS queue) receives only the events that matter to it, optimizing processing and reducing costs.

Example:
Complete the main.tf file with the routing configurations:

resource "aws_cloudwatch_event_rule" "event_rule" {
  name           = "capture-order-created"
  event_bus_name = aws_cloudwatch_event_bus.custom_bus.name
  description    = "Captures order created events"

  event_pattern = jsonencode({
    source      = ["com.mycompany.orders"]
    detail-type = ["OrderCreated"]
  })
}

resource "aws_cloudwatch_event_target" "sqs_target" {
  rule           = aws_cloudwatch_event_rule.event_rule.name
  event_bus_name = aws_cloudwatch_event_bus.custom_bus.name
  target_id      = "SendToSQS"
  arn            = aws_sqs_queue.event_queue.arn
}

To deploy the entire infrastructure, run the commands terraform init, terraform plan, and terraform apply in your terminal.

4. Common Troubleshooting

Even with a well-defined script, infrastructure provisioning can encounter obstacles. Below are the most frequent problems and their solutions:

Access Denied Permissions on the SQS Queue:
What is happening: EventBridge cannot deliver messages to the queue.
How to solve it: Check the aws_sqs_queue_policy. Ensure the EventBridge rule ARN is correct in the security condition. A misconfigured policy will result in the silent discard of events.
Lambda is not triggered by SQS messages:
What is happening: Messages arrive in the queue, but the Python function is not executed.
How to solve it: Validate if the IAM Role linked to the Lambda (lambda_sqs_execution_role) has the AWSLambdaSQSQueueExecutionRole policy properly attached. Lambda needs read permissions (sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes) to consume the data.
Event Pattern Incompatibility:
What is happening: You publish an event to the bus, but it does not appear in the queue.
How to solve it: Verify the accuracy of the injected JSON. The source and detail-type fields sent by the message producer must perfectly match the values stipulated in the event_pattern block of the Terraform rule. EventBridge is case-sensitive.

5. Conclusion

In this tutorial, we built a robust backbone for an event-driven architecture. We configured the structure in code using Terraform, establishing EventBridge as the intelligent traffic router, SQS as the fault-tolerance layer, and Python Lambda as the scalable processing unit.

Mastering this topology empowers you to integrate microservices safely and cleanly. As next steps, I recommend diving into the implementation of Dead Letter Queues (DLQ) for advanced handling of unresolved failures and exploring how this decoupling architectural pattern translates into the design of complex systems in multicloud scenarios.

Road to Golden Jacket: My Journey and Tips for the New AWS SOA-C03 Exam 🚀

Cláudio Filipe Lima Rapôso — Mon, 30 Mar 2026 16:15:52 +0000

When I sat down to take my AWS Certified SysOps Administrator - Associate exam on March 23, I had prepared for a broad range of operational topics. But when the test began, one thing became immediately clear: Amazon CloudWatch was everywhere.

It felt like every other scenario revolved around monitoring, analyzing logs, or troubleshooting performance bottlenecks. Now that AWS has officially transitioned to the new AWS Certified CloudOps Engineer - Associate (SOA-C03) exam, I realize that my heavy CloudWatch experience was actually the best preparation I could have asked for.

Here is a personal look at my exam experience, why CloudWatch is your best friend, and my top tips for anyone tackling the new CloudOps certification.

📈 The CloudWatch Marathon

During my exam on March 23, the monitoring and logging domain was a massive part of the test. I had to know exactly how to trigger alarms, collect logs, and automate responses.

If you are studying for the new SOA-C03 exam, this is even more critical. The domain has been expanded to "Monitoring, Logging, Analysis, Remediation, and Performance Optimization" and now carries the heaviest weight on the exam at 22%,.

To pass, you must understand how to:

Configure and manage the CloudWatch agent to collect metrics and logs not just from EC2 instances, but also from Amazon ECS and Amazon EKS clusters,.
Set up composite alarms and configure them to invoke AWS services directly or through Amazon EventBridge.
Automate remediation tasks using AWS Systems Manager Automation runbooks.

🔄 Bridging the Gap: SysOps to CloudOps

While my exam tested me heavily on traditional monitoring, the new "CloudOps" title reflects a modern shift in cloud operations. If I were taking the SOA-C03 today, here is what I would add to my study list to bridge the gap:

The Container Ecosystem: Containers are now officially in-scope. You need to understand Amazon Elastic Container Registry (ECR), Elastic Container Service (ECS), and Elastic Kubernetes Service (EKS),.
Infrastructure as Code (IaC): The new exam emphasizes creating and managing stacks using AWS CloudFormation and the AWS Cloud Development Kit (AWS CDK),.
Multi-Account Management: Operating in a single account is a thing of the past. You must know how to enforce compliance and manage security across multiple accounts using AWS Organizations, Service Control Policies (SCPs), and AWS Control Tower,.

💡 My Top Tips for Exam Day

Based on my experience in the hot seat, here are my top tips for crushing the exam:

Build a Real Monitoring Lab: Don't just read the docs. Spin up an EC2 instance, install the CloudWatch agent, and create a custom dashboard,. Set up an alarm to trigger an SNS notification or an EventBridge rule, so you see the automated flow in action.
Master Automation: Understand how to use AWS Systems Manager to automate operational processes and remediate issues,.
Eliminate the Noise: AWS questions are famously wordy and the distractors are designed to look plausible. Find the core requirement like "most cost-effective" or "highly available" and eliminate the answers that don't fit.
Embrace the AWS Well-Architected Framework: The exam tests your ability to support workloads according to these best practices,. Always think about how to optimize performance and reliability.

Taking this exam validated my practical skills and proved that I could maintain and secure workloads in the cloud. If you are preparing for the SOA-C03, dive deep into CloudWatch and embrace automation!

💡 Enjoyed it?

If you want to chat about AI, cloud, and architecture, follow me on my socials:

Social Media

I post technical content straight from the front lines. And whenever I discover a time-saving tool that gets the job done right, like this one, you'll hear about it too.

Have you taken the exam yet? Let me know your experience in the comments below! 👇

From Infrastructure to Product: Pipelines into a Profitable SaaS

Cláudio Filipe Lima Rapôso — Thu, 12 Mar 2026 19:12:31 +0000

Open Journal Systems (OJS) is the engine behind thousands of scientific publications worldwide. However, educational institutions, from high schools running literary magazines to universities managing peer-reviewed journals, share a massive pain point: they want to publish research, but they lack the internal IT resources to manage complex PHP monoliths, backups, and server security.

Blending my experience in the classroom with software architecture, I realized this is a massive opportunity. We can move beyond just "hosting" OJS and transform it into a fully automated, Zero-Touch B2B SaaS platform targeted globally at the education sector.

This article details the design, infrastructure, and product strategy to build a highly available, multi-tenant OJS SaaS on Amazon Web Services (AWS) using Terraform, Go, and GitHub Actions.

🏗️ 1. The Reference Architecture on AWS

To sell this globally, we cannot afford manual interventions or local server disks. We must adopt a distributed, stateless, and 100% managed topology.

Core Components:

Compute: Amazon ECS with AWS Fargate. We run the OJS Docker image in a serverless manner. We pay only for the CPU/RAM consumed, which is crucial for maximizing profit margins.
Database: Amazon RDS for MySQL. Fully managed, automated backups, and isolated data tiers.
File Persistence: OJS requires a persistent directory (files_dir) for articles and PDFs. We mount Amazon EFS (Elastic File System) directly to the ECS Task via the NFS protocol.

⚙️ 2. The "Zero-Touch" Provisioning Engine

To turn this infrastructure into a product, the entire customer lifecycle must be automated. Here is how the provisioning engine works:

The Storefront: A university administrator selects a plan on your landing page and checks out.
The Orchestrator (Golang API): For high concurrency and low footprint, a lightweight backend API built in Go listens for the payment gateway webhook (e.g., Stripe).
The Trigger: The Go API automatically calls the GitHub Actions API, passing the tenant_name, region, and tier as JSON payloads.
The Magic: GitHub Actions runs the Terraform scripts. Within minutes, the isolated AWS infrastructure is provisioned, Route53 updates the DNS (journal.university.edu), and the client receives an automated email with their admin credentials.

🌍 Level 1: The System Context Diagram (Business View)

Who it's for: Executives, Investors, University Directors, and non-technical Stakeholders.
What it shows: The "Big Picture." It places our OJS SaaS Platform at the center of the universe and focuses exclusively on answering two questions: Who uses the system? and What other systems do we talk to?

The Actors: It makes it clear that we have different user profiles (the Admin who pays, the Author who publishes, the Reader who consumes).
The External Boundaries: It shows that we didn't build a payment processor from scratch (we use Stripe), we didn't reinvent infrastructure pipelines (we use GitHub Actions), and we integrate with academic industry standards (Crossref).
The Value: Here, technology doesn't matter. There is no AWS, Go, or PHP in this diagram. The focus is purely on the business value flow.

Level 2: The Container Diagram (Solution/Cloud View)

Who it's for: Cloud Architects, DevOps Engineers, Tech Leads, and Security Teams.
What it shows: How the central system (the blue box from Level 1) is divided internally.
(Architectural Note: In the C4 Model, a "Container" means an independently deployable/runnable unit, not necessarily a Docker container, although in our case, they coincide).

Separation of Concerns: The division between the Storefront Web (React Front-end), the Provisioning API (our Go engine), and the Tenant Infrastructure (the client's OJS) is crystal clear.
Technology Choices: This is where the cloud "magic" appears. We show that OJS runs on ECS Fargate (Compute), uses Amazon RDS (Relational Database), and Amazon EFS (Network persistence for PDFs).
Communication Flow: It shows that the Admin doesn't access the database directly; the communication flows from the Browser to the Load Balancer, to the container, and only then to the database via port 3306.

🧩 Level 3: The Component Diagram (Engineering/Code View)

Who it's for: Software Developers (Backend).
What it shows: We take just one of the containers from Level 2 (in this case, our Go Provisioning API) and open the hood to see how the code is structured internally.

Domain Isolation: This is the perfect level to demonstrate Domain-Driven Design (DDD) principles. The Tenant Manager component represents the heart of our domain (where the business rules live).
Dependency Inversion: The diagram shows components like the GitHub API Client and the Metadata Repository. As architects, we want our domain (Tenant Manager) to not depend on specific infrastructure implementations, but rather on interfaces (ports and adapters). The visual flow shows how the business rule delegates the heavy I/O lifting to external clients.
The Webhook Lifecycle: It explains the exact path of the data: The request hits the Router, passes through validation in the Payment Handler, updates the database via the Metadata Repo, and finally triggers the infrastructure via the GitHub Client.

Here is the GitHub Actions workflow that your Go API triggers:

name: 'Zero-Touch SaaS Provisioning'
on:
  workflow_dispatch:
    inputs:
      tenant_name: { description: 'Tenant Name', required: true }
      environment: { description: 'Tier (basic/premium)', required: true }
      aws_region: { description: 'Target Region', required: true }

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ github.event.inputs.aws_region }}

      - name: Terraform Init & Apply
        run: |
          terraform init -backend-config="key=${{ github.event.inputs.tenant_name }}.tfstate"
          terraform apply -var-file="envs/${{ github.event.inputs.environment }}.tfvars.json" -auto-approve

🌍 3. Global Scaling and Data Compliance

Selling to the global education market means navigating strict data privacy laws. Because our infrastructure is codified with Terraform, deploying a compliant environment is just a matter of dynamically injecting the aws_region variable:

GDPR (Europe): If a German university signs up, the automation deploys to eu-central-1 (Frankfurt). The data never leaves Europe.
LGPD (Brazil): For Brazilian institutions, the automation targets sa-east-1 (São Paulo).
FERPA/HIPAA (USA): Medical universities publishing clinical trials can be hosted in isolated, dedicated environments in the US.

💎 4. Tiered Product Strategy (FinOps)

We can structure the SaaS offerings to capture both ends of the academic spectrum, leveraging AWS FinOps strategies:

Tier 1: High School & Small College Plan (High Volume)

Use Case: High school science fairs or small departmental newsletters.
Architecture: Shared ECS resources and a single shared RDS instance with logical separation (different schemas per school).
FinOps: We use Fargate Spot to utilize spare AWS compute capacity for up to a 70% discount. We also use EventBridge to scale the environments down to zero during weekends and school holidays.

Tier 2: University & Research Institute Plan (High Margin)

Use Case: Official university peer-reviewed journals indexing globally with Crossref and DOIs.
Architecture: Dedicated ECS Tasks, isolated RDS instances powered by Graviton (ARM) processors for better price/performance, and custom domain mapping.
Price Point: Premium recurring revenue with strict SLA guarantees and daily automated snapshots.

🐳 5. Dockerizing OJS

The Docker image remains very similar to any standard containerized environment, focusing heavily on the required PHP extensions:

FROM php:8.2-apache

# System dependencies and PHP extensions required for OJS on AWS
RUN apt-get update && apt-get install -y \
    libpng-dev libjpeg-dev libxml2-dev libzip-dev zlib1g-dev libicu-dev g++ \
    && docker-php-ext-configure gd --with-jpeg \
    && docker-php-ext-install gd mysqli opcache zip intl gettext

# Upload Optimizations
RUN { \
    echo 'opcache.memory_consumption=128'; \
    echo 'upload_max_filesize=64M'; \
    echo 'post_max_size=64M'; \
    } > /usr/local/etc/php/conf.d/ojs-optimization.ini

COPY . /var/www/html/
RUN chown -R www-data:www-data /var/www/html/

🛠️ 6. Infrastructure as Code (Terraform)

Governance across the AWS environment is managed via Terraform. The state (.tfstate) is securely stored in Amazon S3 with State Locking handled by DynamoDB.

Below is the critical snippet that connects ECS (Fargate) to EFS to persist the PDFs:

# 1. Amazon RDS MySQL
resource "aws_db_instance" "ojs_db" {
  identifier           = "ojs-db-${var.environment}"
  allocated_storage    = 20
  engine               = "mysql"
  engine_version       = "8.0"
  instance_class       = var.db_instance_class
  username             = var.db_user
  password             = var.db_password
  vpc_security_group_ids = [aws_security_group.rds_sg.id]
  db_subnet_group_name = aws_db_subnet_group.main.name
  skip_final_snapshot  = true
}

# 2. Amazon EFS for the files directory
resource "aws_efs_file_system" "ojs_files" {
  creation_token = "ojs-efs-${var.environment}"
  encrypted      = true
}

# 3. ECS Task Definition (Fargate) with EFS Volume
resource "aws_ecs_task_definition" "ojs_task" {
  family                   = "ojs-app-${var.environment}"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = var.fargate_cpu
  memory                   = var.fargate_memory

  container_definitions = jsonencode([{
    name  = "ojs-container"
    image = var.ecr_image_url
    mountPoints = [{
      sourceVolume  = "ojs-efs-volume"
      containerPath = "/var/www/ojsdata"
    }]
    environment = [
      { name = "MYSQL_HOST", value = aws_db_instance.ojs_db.address }
    ]
  }])

  volume {
    name = "ojs-efs-volume"
    efs_volume_configuration {
      file_system_id = aws_efs_file_system.ojs_files.id
      transit_encryption = "ENABLED"
    }
  }
}

Variable Injection (FinOps)

We define instance sizes via JSON (prod.tfvars.json) to control costs per environment:

{
  "environment": "prod",
  "region": "us-east-1",
  "fargate_cpu": "1024",
  "fargate_memory": "2048",
  "db_instance_class": "db.t4g.medium",
  "db_user": "ojsadmin"
}

🚀 7. CI/CD with GitHub Actions

The automated deployment pipeline checks out the code, configures AWS credentials, and updates the infrastructure via Terraform.

name: 'Deploy OJS AWS'
on:
  workflow_dispatch:
    inputs:
      tenant_name: { description: 'Tenant Name', required: true }
      environment: { description: 'Environment (dev/hom/prod)', required: true }

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Terraform Init (S3 Backend)
        run: |
          terraform init \
            -backend-config="bucket=ojs-terraform-state-central" \
            -backend-config="key=${{ github.event.inputs.tenant_name }}.${{ github.event.inputs.environment }}.tfstate" \
            -backend-config="dynamodb_table=terraform-lock"

      - name: Terraform Apply
        env:
          TF_VAR_db_password: ${{ secrets.DB_PASSWORD }}
        run: |
          terraform apply \
            -var-file="envs/${{ github.event.inputs.environment }}.tfvars.json" \
            -auto-approve

💰 8. FinOps: Cost Optimization on AWS

AWS provides fantastic mechanisms to slash costs in non-production environments:

Fargate Spot: In Dev/Hom environments, we configure the ECS Capacity Provider to use Fargate Spot, utilizing spare AWS compute capacity for up to a 70% discount.
Graviton (ARM): We use RDS instances powered by Graviton processors (db.t4g), which deliver better performance at a lower price point than the x86 architecture.
Scheduling Automation: We leverage Amazon EventBridge to trigger an AWS Lambda function that stops the RDS instance and scales the ECS Desired Count to 0 outside of regular business hours.

🎯 Conclusion

By bridging the gap between software architecture and the needs of the classroom, we can transform Open Journal Systems from a complex IT burden into a seamless, globally scalable SaaS product. The combination of AWS ECS Fargate for horizontal scalability, Go for rapid API orchestration, and Terraform for compliant IaC delivers a true, zero-touch EdTech platform.

Have you ever thought about productizing open-source software into a niche B2B SaaS? Share your thoughts and architectural approaches in the comments! 👇

Reason Your Python Code is Hard to Test with Single Responsibility Principle, And How to Fix It! (Portuguese version)

Cláudio Filipe Lima Rapôso — Mon, 29 Dec 2025 19:43:37 +0000

O Princípio da Responsabilidade Única (SRP - Single Responsibility Principle) é a base dos princípios SOLID. Ele estabelece que uma classe deve ter um, e apenas um, motivo para mudar.

Quando ignoramos esse princípio, criamos "God Classes" (Classes Deus) componentes que sabem demais e fazem demais. Essas classes são frágeis: uma mudança no banco de dados pode quebrar a lógica de validação, ou uma alteração nas regras de negócio pode quebrar o sistema de envio de e-mails.

Neste guia, analisaremos um antipadrão comum em uma funcionalidade de Cadastro de Usuário e a refatoraremos para uma arquitetura limpa e desacoplada.

❌ O "Antes": A Violação do SRP

Aqui está um exemplo típico de código legado. Temos uma classe chamada UserService, mas ela não está agindo como um serviço; ela age como um monolito.

Por que isso é ruim:

Alto Acoplamento: Ela está fortemente ligada a regras de validação específicas e instruções de banco de dados (print).
Difícil de Testar: Você não consegue testar a lógica de registro sem acionar a lógica do banco de dados.
Múltiplos Motivos para Mudar: Se as regras de senha mudarem, este arquivo é aberto. Se o banco de dados mudar, este arquivo também é aberto.

class UserService:
    def register(self, name, email, password):
        # Responsabilidade 1: Lógica de Validação
        if len(name) < 3:
            raise ValueError("O nome é muito curto")
        if "@" not in email:
            raise ValueError("Email inválido")
        if len(password) < 6:
            raise ValueError("A senha é muito fraca")

        # Responsabilidade 2: Lógica de Banco de Dados (Verificar existência)
        print(f"[DB] Verificando se {email} existe...")
        if email == "taken@example.com":
             raise ValueError("Email já está em uso")

        # Responsabilidade 3: Lógica de Persistência (Salvar)
        print(f"[DB] INSERT INTO users (name, email) VALUES ('{name}', '{email}')")

        # Responsabilidade 4: Lógica de Notificação
        print(f"[MAIL] Enviando e-mail de boas-vindas para {email}...")

Uso

service = UserService()
service.register("Alice", "alice@example.com", "123456")

✅ A Refatoração: Separação de Preocupações

Para corrigir isso, devemos identificar as responsabilidades distintas e extraí-las para suas próprias classes.

1. A Entidade (Estrutura de Dados)

Primeiro, criamos uma representação dos dados. Esta classe não tem lógica; ela apenas armazena estado.

Motivo para mudar: Apenas se os atributos do usuário (como adicionar telefone) mudarem.

from dataclasses import dataclass

@dataclass
class User:
    name: str
    email: str
    password: str

2. O Validador (Regras de Negócio)

Extraímos as regras de validação. Esta classe garante a integridade dos dados.

Motivo para mudar: Apenas se as regras para dados válidos mudarem.

class UserValidator:
    def validate(self, user: User):
        if len(user.name) < 3:
            raise ValueError("O nome é muito curto")
        if "@" not in user.email:
            raise ValueError("Email inválido")
        if len(user.password) < 6:
            raise ValueError("A senha é muito fraca")

3. O Repositório (Persistência)

Abstraímos as operações de banco de dados. Esta classe lida com o "Como" armazenar os dados.

Motivo para mudar: Apenas se a tecnologia do banco de dados (SQL, NoSQL, Arquivo) mudar.

class UserRepository:
    def exists(self, email: str) -> bool:
        # Simula verificação no DB
        return email == "taken@example.com"

    def save(self, user: User):
        # Simula salvamento no DB
        print(f"[DB] INSERT INTO users VALUES ('{user.name}', '{user.email}')")

4. O Serviço (O Orquestrador)

Finalmente, reescrevemos o UserService. Note como ele ficou limpo. Ele não sabe como validar ou como salvar; ele simplesmente delega essas tarefas para os especialistas (as dependências injetadas).

Motivo para mudar: Apenas se o fluxo de trabalho do cadastro mudar (ex: adicionar uma etapa para verificar o telefone via SMS).

class UserService:
    def __init__(self, validator: UserValidator, repository: UserRepository):
        # Injeção de Dependência: Pedimos as ferramentas que precisamos
        self.validator = validator
        self.repository = repository

    def register(self, name, email, password):
        user = User(name, email, password)

        # Passo 1: Validar
        self.validator.validate(user)

        # Passo 2: Verificar Regras de Negócio
        if self.repository.exists(email):
            raise ValueError("Email já está em uso")

        # Passo 3: Persistir
        self.repository.save(user)

        print(">>> Usuário registrado com sucesso.")

Exemplo de Uso

Ao conectar os componentes ("wiring"), criamos um sistema flexível.

    # 1. Configurar as dependências
    repo = UserRepository()
    val = UserValidator()

    # 2. Injetar dependências no Serviço
    service = UserService(validator=val, repository=repo)

    # 3. Executar a lógica
    try:
        service.register("Bob", "bob@example.com", "senhaSegura123")
    except ValueError as e:
        print(f"Erro: {e}")

Conclusão

Ao aplicar o Princípio da Responsabilidade Única, transformamos um script rígido em uma arquitetura de software profissional.

Os benefícios dessa abordagem são claros:

Testabilidade: Agora você pode criar testes unitários para o UserValidator isoladamente, sem precisar de um banco de dados falso.
Manutenibilidade: Se o esquema do banco de dados mudar, você edita apenas o UserRepository. O UserService permanece intocado.
Legibilidade: O UserService agora lê como uma história de alto nível sobre o que acontece, em vez de uma lista bagunçada de como acontece.

Essa separação reduz a carga cognitiva sobre o desenvolvedor e garante que sua aplicação seja robusta o suficiente para lidar com mudanças futuras com risco mínimo.

Bot de Monitoramento para SushiSwap V3 em Go — Parte 1

Cláudio Filipe Lima Rapôso — Tue, 30 Sep 2025 20:13:30 +0000

Este guia descreve, de forma contínua e didática, como construir a primeira metade de um bot de trading em Go. Nesta etapa não há transações on-chain. O programa observa o preço em dólar de um token de referência, compara esse valor com limites configurados em um arquivo .env e decide, de maneira simulada, quando compraria e quando venderia. O objetivo é validar lógica e parâmetros sem risco financeiro, além de introduzir a persistência do estado em SQLite para que o bot possa ser interrompido e retomado sem perder contexto.

Conceito e fluxo

O comportamento é simples. O aplicativo carrega as configurações do .env, consulta periodicamente o preço em USD do token de referência por HTTP e imprime no console o valor atual. Se o preço observado estiver abaixo ou igual ao alvo de compra e ainda não houver posição aberta, considera-se uma entrada e o estado é salvo no banco com a informação do preço de entrada. Se, com posição aberta, o preço atingir o alvo de lucro, considera-se a saída e o estado é atualizado para indicar que não há mais posição. Em qualquer outro caso, o programa apenas aguarda. Como não há transações nesta fase, tratamos essas decisões como um simulador de gatilhos, útil para ajustar parâmetros e entender o ciclo de execução.

Preparação do ambiente

É necessário ter Go instalado em versão recente. Crie uma pasta para o projeto, inicialize um módulo e instale as dependências. O pacote godotenv carrega variáveis do arquivo .env e o driver modernc.org/sqlite possibilita usar SQLite sem CGO, o que simplifica a portabilidade.

mkdir sushiswap-v3-go && cd sushiswap-v3-go
go mod init example.com/sushiswap-v3-go
go get github.com/joho/godotenv
go get modernc.org/sqlite

Configuração com `.env`

Crie um arquivo .env na raiz do projeto. Ele concentra variáveis de rede e parâmetros de estratégia. Também indicamos DB_PATH, o caminho do arquivo SQLite que manterá o estado.

CHAIN_ID=11155111
NETWORK=sepolia
INFURA_API_KEY=SUA_INFURA_KEY

TOKEN0_ADDRESS=0xfFf9976782d46CC05630D1f6eBAb18b2324d6B14
TOKEN1_ADDRESS=0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238

QUOTE0_ADDRESS=0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2

WALLET=0xSUA_WALLET
PRIVATE_KEY=0xSUA_PRIVATE_KEY

ROUTER_ADDRESS=0x3b0aa7d38bf3c103bf02d1de2e37568cbed3d6e8

PRICE_TO_BUY=5000
AMOUNT_TO_BUY=0.1
PROFITABILITY=1.1

DB_PATH=./bot.db

A variável QUOTE0_ADDRESS representa o token cujo preço em USD será observado; no exemplo, usa-se o WETH da mainnet por ser uma referência líquida e amplamente utilizada. As variáveis PRICE_TO_BUY e PROFITABILITY definem, respectivamente, o alvo de entrada e o multiplicador do alvo de lucro. As chaves de carteira e o endereço do router são armazenados desde já, embora só venham a ser utilizadas na fase seguinte, quando forem adicionadas transações reais. Recomenda-se manter o arquivo .env fora do controle de versão.

Implementação do código

A seguir estão os arquivos Go, organizados por responsabilidade. Basta criar cada arquivo com o conteúdo indicado.

`config.go`

Este módulo lê e valida o .env, convertendo valores numéricos e garantindo que os campos mínimos existam para a execução desta etapa. Se faltar algo essencial, a função sinaliza claramente o problema.

package main

import (
    "fmt"
    "os"
    "strconv"

    "github.com/joho/godotenv"
)

type Config struct {
    ChainID       int
    Network       string
    InfuraAPIKey  string
    Token0Address string
    Token1Address string
    Quote0Address string
    Wallet        string
    PrivateKey    string
    RouterAddress string
    PriceToBuy    float64
    AmountToBuy   string
    Profitability float64
    DBPath        string
}

func LoadConfig() (*Config, error) {
    _ = godotenv.Load()

    var err error
    cfg := &Config{}

    if v := os.Getenv("CHAIN_ID"); v != "" {
        if cfg.ChainID, err = strconv.Atoi(v); err != nil {
            return nil, fmt.Errorf("CHAIN_ID inválido: %w", err)
        }
    } else {
        cfg.ChainID = 11155111
    }

    cfg.Network = os.Getenv("NETWORK")
    cfg.InfuraAPIKey = os.Getenv("INFURA_API_KEY")
    cfg.Token0Address = os.Getenv("TOKEN0_ADDRESS")
    cfg.Token1Address = os.Getenv("TOKEN1_ADDRESS")
    cfg.Quote0Address = os.Getenv("QUOTE0_ADDRESS")
    cfg.Wallet = os.Getenv("WALLET")
    cfg.PrivateKey = os.Getenv("PRIVATE_KEY")
    cfg.RouterAddress = os.Getenv("ROUTER_ADDRESS")
    cfg.AmountToBuy = os.Getenv("AMOUNT_TO_BUY")

    if v := os.Getenv("PRICE_TO_BUY"); v != "" {
        if cfg.PriceToBuy, err = strconv.ParseFloat(v, 64); err != nil {
            return nil, fmt.Errorf("PRICE_TO_BUY inválido: %w", err)
        }
    } else {
        return nil, fmt.Errorf("PRICE_TO_BUY ausente")
    }

    if v := os.Getenv("PROFITABILITY"); v != "" {
        if cfg.Profitability, err = strconv.ParseFloat(v, 64); err != nil {
            return nil, fmt.Errorf("PROFITABILITY inválido: %w", err)
        }
    } else {
        return nil, fmt.Errorf("PROFITABILITY ausente")
    }

    if cfg.Quote0Address == "" {
        return nil, fmt.Errorf("QUOTE0_ADDRESS ausente")
    }

    if v := os.Getenv("DB_PATH"); v != "" {
        cfg.DBPath = v
    } else {
        cfg.DBPath = "./bot.db"
    }

    return cfg, nil
}

`database.go`

Este módulo cria e inicializa o banco SQLite, além de oferecer funções para ler e salvar o estado do bot. O estado se restringe a duas informações: se há ou não posição aberta e qual foi o preço de entrada, quando aplicável. Ao iniciar pela primeira vez, uma linha padrão é criada para garantir que o acesso seja simples e previsível nas execuções subsequentes.

package main

import (
    "database/sql"
    "fmt"

    _ "modernc.org/sqlite"
)

type BotState struct {
    IsOpened   bool
    EntryPrice *float64
}

func InitDB(path string) (*sql.DB, error) {
    db, err := sql.Open("sqlite", path)
    if err != nil {
        return nil, fmt.Errorf("erro abrindo sqlite: %w", err)
    }
    schema := `
    CREATE TABLE IF NOT EXISTS bot_state (
        id INTEGER PRIMARY KEY CHECK (id = 1),
        is_opened INTEGER NOT NULL,
        entry_price REAL
    );
    INSERT INTO bot_state (id, is_opened, entry_price)
        SELECT 1, 0, NULL
        WHERE NOT EXISTS (SELECT 1 FROM bot_state WHERE id = 1);
    `
    if _, err := db.Exec(schema); err != nil {
        return nil, fmt.Errorf("erro criando schema: %w", err)
    }
    return db, nil
}

func LoadBotState(db *sql.DB) (*BotState, error) {
    row := db.QueryRow(`SELECT is_opened, entry_price FROM bot_state WHERE id = 1`)
    var isOpenedInt int
    var entryPrice sql.NullFloat64
    if err := row.Scan(&isOpenedInt, &entryPrice); err != nil {
        return nil, fmt.Errorf("erro lendo estado: %w", err)
    }
    var ep *float64
    if entryPrice.Valid {
        v := entryPrice.Float64
        ep = &v
    }
    return &BotState{
        IsOpened:   isOpenedInt == 1,
        EntryPrice: ep,
    }, nil
}

func SaveBotState(db *sql.DB, st *BotState) error {
    var isOpenedInt int
    if st.IsOpened {
        isOpenedInt = 1
    } else {
        isOpenedInt = 0
    }

    var entry interface{}
    if st.EntryPrice != nil {
        entry = *st.EntryPrice
    }

    if _, err := db.Exec(
        `UPDATE bot_state SET is_opened = ?, entry_price = ? WHERE id = 1`,
        isOpenedInt, entry,
    ); err != nil {
        return fmt.Errorf("erro salvando estado: %w", err)
    }
    return nil
}

`prices.go`

Esta unidade contém a função que consulta a API pública de preços. O retorno esperado é um número de ponto flutuante representando o preço em USD do token indicado. A configuração de timeout e a verificação do status HTTP ajudam a tornar o comportamento previsível.

package main

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "time"
)

func fetchPriceUSD(tokenAddress string) (float64, error) {
    url := fmt.Sprintf("https://api.sushi.com/price/v1/%d/%s", 1, tokenAddress)

    req, _ := http.NewRequest(http.MethodGet, url, nil)
    req.Header.Set("Accept", "application/json")

    client := &http.Client{Timeout: 10 * time.Second}
    res, err := client.Do(req)
    if err != nil {
        return 0, err
    }
    defer res.Body.Close()

    if res.StatusCode != http.StatusOK {
        body, _ := io.ReadAll(res.Body)
        return 0, fmt.Errorf("pricing api status %d: %s", res.StatusCode, string(body))
    }

    var price float64
    if err := json.NewDecoder(res.Body).Decode(&price); err != nil {
        return 0, fmt.Errorf("falha ao decodificar preço: %w", err)
    }
    return price, nil
}

`main.go`

O arquivo principal integra as partes. Ao iniciar, o programa carrega a configuração, prepara o banco, recupera o estado e entra em um ciclo que consulta o preço, imprime o valor e executa a lógica de decisão, atualizando o SQLite sempre que houver mudanças de estado. Um comando para limpar a tela mantém o console com aparência de painel.

package main

import (
    "fmt"
    "log"
    "time"
)

func monitor(cfg *Config) (float64, error) {
    price, err := fetchPriceUSD(cfg.Quote0Address)
    if err != nil {
        return 0, err
    }
    fmt.Print("\033[2J\033[H")
    fmt.Println("Price:", price)
    return price, nil
}

func main() {
    cfg, err := LoadConfig()
    if err != nil {
        log.Fatalf("config erro: %v", err)
    }

    db, err := InitDB(cfg.DBPath)
    if err != nil {
        log.Fatalf("db erro: %v", err)
    }
    defer db.Close()

    state, err := LoadBotState(db)
    if err != nil {
        log.Fatalf("erro carregando estado: %v", err)
    }

    cycle := func() {
        price, err := monitor(cfg)
        if err != nil {
            log.Printf("erro monitorando preço: %v", err)
            return
        }

        if !state.IsOpened && price <= cfg.PriceToBuy {
            state.IsOpened = true
            state.EntryPrice = &price
            if err := SaveBotState(db, state); err != nil {
                log.Printf("erro salvando estado (swap in): %v", err)
            }
            fmt.Printf("Swap in (entry=%.6f)\n", price)
            return
        }

        target := cfg.PriceToBuy * cfg.Profitability
        if state.IsOpened && price >= target {
            state.IsOpened = false
            state.EntryPrice = nil
            if err := SaveBotState(db, state); err != nil {
                log.Printf("erro salvando estado (swap out): %v", err)
            }
            fmt.Printf("Swap out (target=%.6f)\n", target)
            return
        }

        if state.IsOpened && state.EntryPrice != nil {
            fmt.Printf("Wait... (opened at %.6f, target %.6f)\n", *state.EntryPrice, target)
            return
        }

        fmt.Println("Wait...")
    }

    cycle()
    ticker := time.NewTicker(10 * time.Second)
    defer ticker.Stop()
    for range ticker.C {
        cycle()
    }
}

Execução

Com os arquivos criados e o .env preenchido, execute o projeto a partir da raiz. O console exibirá o preço e a decisão correspondente do ciclo. Quando o preço atingir o alvo de compra, aparecerá a indicação de entrada e o estado será salvo. Quando alcançar o alvo de lucro com posição aberta, a saída será registrada. Se o programa for encerrado e reiniciado, a leitura do banco restaurará a situação anterior.

go run .

Encerramento

Com esta base consolidada, você tem um esqueleto funcional capaz de observar preço, tomar decisões simuladas e manter consistência entre execuções por meio de SQLite. Na Parte 2, em vez de montar e enviar a transação on-chain localmente, o fluxo de swap será executado via gRPC: o cliente em Go fará chamadas a um serviço gRPC responsável por cotar e processar a operação de compra e venda. Esse serviço receberá parâmetros como chain_id, token_in, token_out, amount, max_slippage e wallet, retornará métricas de pré-troca (por exemplo, o assumedAmountOut) e cuidará da preparação/execução da transação, incluindo roteamento, montagem do payload, assinatura e envio, além do retorno do hash e do recibo quando confirmada.

Do ponto de vista de arquitetura, o cliente Go apenas disciplina a orquestração: abre o canal gRPC, envia a requisição de Quote/Execute, aguarda a resposta (com sucesso ou erro tratado) e registra estado/telemetria. O serviço gRPC concentra a lógica sensível: integração com o roteador (para encontrar a melhor rota), aplicação de slippage máxima, políticas de deadline e retries, idempotência por chave, auditoria, observabilidade e segurança de chaves (sem trafegar PRIVATE_KEY pelo cliente). A assinatura pode ficar no servidor (HSM, KMS ou cofre) ou ser separada em um signer dedicado, mantendo o cliente leve e sem material sensível.

Finalmente, a evolução natural é: o bot em Go continua decidindo quando agir, persiste o estado no SQLite, e a execução do swap passa a ser um contrato gRPC bem definido com protobufs para cotação e execução, entregando robustez operacional, isolamento de segredos e padronização de erros/logs para produção.

Referências

Go. (2025, 25 fevereiro). The Go programming language specification. go.dev. https://go.dev/ref/spec (Go)

Go. (n.d.). Documentation. go.dev. https://go.dev/doc/ (Go)

gRPC. (2024, 25 novembro). Basics tutorial | Go. grpc.io. https://grpc.io/docs/languages/go/basics/ (gRPC)

gRPC. (2024, 25 novembro). Quick start | Go. grpc.io. https://grpc.io/docs/languages/go/quickstart/ (gRPC)

Protocol Buffers. (n.d.). Protocol buffer basics: Go. protobuf.dev. https://protobuf.dev/getting-started/gotutorial/ (protobuf.dev)

Equipe go-ethereum (Geth). (2024, 24 maio). Getting started with Geth. geth.ethereum.org. https://geth.ethereum.org/docs/getting-started (go-ethereum)

Go Ethereum. (n.d.). github.com/ethereum/go-ethereum (API em Go). pkg.go.dev. https://pkg.go.dev/github.com/ethereum/go-ethereum (Go Packages)

modernc.org. (2025, 11 agosto). sqlite package (driver SQLite sem CGO). pkg.go.dev. https://pkg.go.dev/modernc.org/sqlite (Go Packages)

Joho. (n.d.). joho/godotenv [Repositório]. GitHub. https://github.com/joho/godotenv (GitHub)

Sushi. (2025, 13 setembro). Pricing API documentation. docs.sushi.com. https://docs.sushi.com/api/examples/pricing (docs.sushi.com)

gRPC-Go. (n.d.). google.golang.org/grpc (pacote em Go). pkg.go.dev. https://pkg.go.dev/google.golang.org/grpc (Go Packages)

💡Curtiu?

Se quiser trocar ideia sobre IA, cloud e arquitetura, me segue nas redes:

Redes Sociais

Publico conteúdos técnicos direto do campo de batalha. E quando descubro uma ferramenta que economiza tempo e resolve bem, como essa, você fica sabendo também.

Autenticação Segura com Microsoft Entra ID para desenvolvedores Typescript

Cláudio Filipe Lima Rapôso — Tue, 23 Sep 2025 18:32:42 +0000

Aplicações modernas funcionam raramente isoladas. Muitas vezes temos um frontend que lida com a experiência do usuário, e um backend que concentra as regras de negócio e o acesso a dados sensíveis.
Garantir que apenas usuários autenticados consigam acessar esses recursos é fundamental.

Neste artigo, vamos construir uma solução que utiliza Next.js como frontend, integrando a autenticação com o Microsoft Entra ID (antigo Azure Active Directory), e um backend em Node/TypeScript que valida tokens JWT emitidos pelo Entra ID antes de liberar o acesso a rotas protegidas.

Arquitetura Geral

A solução pode ser entendida em cinco passos principais:

O usuário acessa a aplicação em Next.js e inicia o login.
O NextAuth.js redireciona o usuário para o Microsoft Entra ID.
Após a autenticação, o Entra ID retorna um ID Token e um Access Token para o Next.js.
O frontend envia o Access Token ao backend, no header Authorization: Bearer <token>.
O backend valida o token contra o serviço de chaves públicas (JWKS) do Entra ID.

Se válido → rota protegida é acessada.
Se inválido/expirado → resposta 401 Unauthorized.

1. Configuração no Entra ID

No Azure Portal:

Vá em Microsoft Entra ID → App registrations → New registration.
Preencha os campos:
- Name: nextjs-auth-app
- Redirect URI: http://localhost:3000/api/auth/callback
- Ative ID tokens e Access tokens.
Salve as credenciais:
- Application (client) ID
- Directory (tenant) ID
- Client Secret (criado manualmente em Certificates & secrets).

2. Frontend Next.js com NextAuth

Instalação

npm install next-auth @azure/msal-node

Variáveis de ambiente

Arquivo .env.local:

AZURE_AD_CLIENT_ID=<Application ID>       # ID da aplicação registrada no Entra ID
AZURE_AD_CLIENT_SECRET=<Client Secret>    # Segredo do app (não expor no frontend)
AZURE_AD_TENANT_ID=<Directory ID>         # Tenant (diretório da organização)
NEXTAUTH_URL=http://localhost:3000        # URL da aplicação Next.js
NEXTAUTH_SECRET=<chave-aleatória>         # Chave para assinar JWT de sessão

Configuração do NextAuth

import NextAuth from "next-auth";
import AzureADProvider from "next-auth/providers/azure-ad";

// Configuração principal do NextAuth
export default NextAuth({
  providers: [
    // Habilita login com Microsoft Entra ID (Azure AD)
    AzureADProvider({
      clientId: process.env.AZURE_AD_CLIENT_ID!,        // ID do app registrado no Entra ID
      clientSecret: process.env.AZURE_AD_CLIENT_SECRET!,// Segredo do cliente (guardado no backend)
      tenantId: process.env.AZURE_AD_TENANT_ID!,        // ID do diretório (tenant)
    }),
  ],
  session: { strategy: "jwt" }, // Sessões baseadas em JWT (sem persistência no BD)
  callbacks: {
    // Callback executado ao criar/atualizar JWT
    async jwt({ token, account }) {
      if (account) token.accessToken = account.access_token; // Armazena o accessToken no token
      return token;
    },
    // Callback executado ao montar a sessão
    async session({ session, token }) {
      session.accessToken = token.accessToken as string; // Inclui o accessToken na sessão
      return session;
    },
  },
});

Componente de Login/Logout (`AuthButton.tsx`)

"use client"; // Necessário porque usamos interações de browser (signIn/signOut)

import { signIn, signOut, useSession } from "next-auth/react";

export default function AuthButton() {
  const { data: session } = useSession(); // Hook que recupera a sessão atual

  if (session) {
    // Caso o usuário esteja logado
    return (
      <button onClick={() => signOut()}>
        Sair ({session.user?.name}) {/* Mostra o nome do usuário logado */}
      </button>
    );
  }
  // Caso não esteja logado
  return (
    <button onClick={() => signIn("azure-ad")}>
      Entrar com Entra ID {/* Chama fluxo de login no Entra ID */}
    </button>
  );
}

Tela Principal (`page.tsx`)

import AuthButton from "./components/AuthButton"; // Importa o botão de login/logout
import Link from "next/link";

export default function Home() {
  return (
    <main style={{ padding: "2rem" }}>
      <h1>🔐 Demo de Autenticação com Entra ID</h1>
      {/* Botão que mostra "Entrar" ou "Sair", dependendo da sessão */}
      <AuthButton />

      <hr style={{ margin: "2rem 0" }} />

      {/* Link para acessar página protegida */}
      <Link href="/protected">
        <button>Acessar página protegida</button>
      </Link>
    </main>
  );
}

3. Server Component: Página Protegida

import { authOptions } from "../api/auth/[...nextauth]/route";
import { getServerSession } from "next-auth";

export default async function ProtectedPage() {
  // Recupera a sessão no lado do servidor
  const session = await getServerSession(authOptions);

  if (!session) {
    // Caso o usuário não esteja autenticado
    return <p>Você precisa estar logado.</p>;
  }

  // Faz requisição ao backend protegido enviando o accessToken no header
  const res = await fetch("http://localhost:4000/api/secure-data", {
    headers: {
      Authorization: `Bearer ${session.accessToken}`, // Token nunca vai para o client
    },
    cache: "no-store", // Garante que não será cacheado
  });

  const data = await res.json();

  return (
    <div>
      <h2>Olá, {session.user?.name}</h2> {/* Nome do usuário logado */}
      <pre>{JSON.stringify(data, null, 2)}</pre> {/* Dados retornados da API */}
    </div>
  );
}

4. Backend Node/TypeScript

Dependências

npm install express jwks-rsa express-jwt

Código (`src/index.ts`)

import express from "express";
import { expressjwt as jwt } from "express-jwt";
import jwksRsa from "jwks-rsa";

const app = express();
const port = 4000;

// Middleware que valida o JWT recebido
const checkJwt = jwt({
  // Define a forma de obter as chaves públicas do Entra ID
  secret: jwksRsa.expressJwtSecret({
    cache: true,                      // Cache para não buscar chave toda vez
    rateLimit: true,                  // Limite de requisições para JWKS
    jwksRequestsPerMinute: 10,        // Máx. 10 req/min
    jwksUri: `https://login.microsoftonline.com/${process.env.AZURE_AD_TENANT_ID}/discovery/v2.0/keys`,
  }) as any,
  audience: process.env.AZURE_AD_CLIENT_ID,               // Valida se o token é para este app
  issuer: `https://login.microsoftonline.com/${process.env.AZURE_AD_TENANT_ID}/v2.0`, // Origem do token
  algorithms: ["RS256"],                                  // Algoritmo esperado
});

// Rota protegida: só acessa se o JWT for válido
app.get("/api/secure-data", checkJwt, (req, res) => {
  res.json({
    message: "Autenticado ✅",
    claims: (req as any).auth, // Retorna as claims do token decodificado
  });
});

// Inicializa o servidor
app.listen(port, () =>
  console.log(`🚀 Backend rodando em http://localhost:${port}`)
);

Boas Práticas

Proteção de secrets: nunca exponha clientSecret no frontend.
Sessões seguras: use cookies httpOnly ou JWT fornecidos pelo NextAuth.
Validação rigorosa: configure corretamente audience e issuer.
Observabilidade: registre logs de falhas de autenticação.
Escalabilidade: esse padrão permite múltiplos serviços validando tokens sem depender do frontend.

Conclusão

Com essa arquitetura, garantimos um fluxo seguro de ponta a ponta:

O Next.js gerencia autenticação e sessão do usuário.
O backend Node/TS valida tokens antes de liberar dados sensíveis.
O Microsoft Entra ID centraliza a identidade, oferecendo segurança corporativa.

Esse modelo é flexível e pode ser expandido para microsserviços ou integração com APIs da Microsoft (Graph API).

Referências

Microsoft Corporation. (2024a). Microsoft identity platform documentation. Microsoft Learn.
https://learn.microsoft.com/en-us/azure/active-directory/develop/
Microsoft Corporation. (2024b). Microsoft Entra ID: Overview. Microsoft Learn.
https://learn.microsoft.com/en-us/entra/identity/
Microsoft Corporation. (2024c). Configure NextAuth.js with Azure AD. Microsoft Learn.
https://learn.microsoft.com/en-us/azure/active-directory/develop/tutorial-v2-javascript-spa
NextAuth.js. (2024). NextAuth.js Documentation.
https://next-auth.js.org/
Auth0 Inc. (2024). Introduction to JWTs.
https://auth0.com/intro-to-jwt

Criando um Sidecar em Go para acessar o Microsoft Graph via gRPC

Cláudio Filipe Lima Rapôso — Thu, 18 Sep 2025 11:20:29 +0000

O Microsoft Graph é a porta de entrada para os serviços da Microsoft 365. Ele permite acessar informações como:

Dados de usuários e grupos.
Emails e calendários do Outlook.
Arquivos no OneDrive.
Mensagens no Teams.

Mas para chamar o Graph, não basta fazer um GET com http.Client.
É necessário autenticar via Microsoft Entra ID (antigo Azure Active Directory), obter um Access Token OAuth2, e então usá-lo em cada requisição.

👉 Isso pode complicar a aplicação principal, que precisa conhecer detalhes de autenticação.
Uma solução elegante é usar o padrão Sidecar: um serviço auxiliar, rodando ao lado da aplicação, que cuida dessa complexidade.

1. O que é um Sidecar?

Imagine que você tem uma aplicação (em Go, .NET, Python, etc) que precisa acessar o Graph.

Você pode embutir a lógica de autenticação dentro dela. Mas, se várias aplicações precisarem fazer isso, você terá código duplicado em todos os lugares.

O sidecar resolve esse problema:

É um pequeno serviço separado (nesse caso em Go) que fica rodando ao lado da aplicação.
Ele fala com o Microsoft Entra ID para buscar tokens.
Ele chama o Microsoft Graph.
Ele expõe uma API simples (via gRPC) para que a aplicação principal possa apenas pedir:

"Me dê os dados do usuário X"
E o sidecar cuida do resto.

📌 Em arquiteturas Kubernetes, o sidecar roda no mesmo pod da aplicação principal.

Isso significa que a aplicação acessa o sidecar por localhost, sem depender da rede externa.

2. Arquitetura

📌 O que acontece:

A aplicação chama GetUser no sidecar.
O sidecar verifica se já tem um Access Token válido em cache.

Se não tiver, pede um novo ao Microsoft Entra ID.
1. O sidecar chama o Microsoft Graph passando o token no header.
2. O Graph devolve os dados do usuário.
3. O sidecar converte para UserResponse e devolve para a aplicação via gRPC.

3. Definindo o contrato gRPC

Antes do código Go, precisamos definir o contrato de comunicação.

Crie o arquivo graph.proto:

syntax = "proto3";

package graph;

// Serviço que o sidecar vai expor
service GraphService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

// Requisição: o cliente pode passar um user_id
// Se vazio, o sidecar consulta o "me" (usuário atual)
message UserRequest {
  string user_id = 1;
}

// Resposta: dados básicos do usuário no Graph
message UserResponse {
  string id = 1;
  string display_name = 2;
  string given_name = 3;
  string surname = 4;
  string user_principal_name = 5;
}

Explicando

O serviço GraphService expõe o método GetUser.
UserRequest permite consultar um usuário específico (users/{id}) ou o próprio usuário (me).
UserResponse retorna alguns campos comuns do Graph.

Gerando código Go

Com o protoc instalado, rode:

protoc --go_out=. --go-grpc_out=. graph.proto

Isso gera os arquivos .pb.go, que contêm as interfaces gRPC que implementaremos.

4. Implementando o sidecar em Go

4.1 Estrutura base

Crie um arquivo sidecar.go:

package main

import (
    "bytes"
    "context"
    "encoding/json"
    "fmt"
    "io"
    "net"
    "net/http"
    "os"
    "sync"
    "time"

    pb "example.com/graph/proto" // ajuste para o caminho correto
    "google.golang.org/grpc"
)

const (
    tokenURL = "https://login.microsoftonline.com/%s/oauth2/v2.0/token"
    graphURL = "https://graph.microsoft.com/v1.0/%s"
)

// Servidor gRPC que vai rodar como sidecar
type server struct {
    pb.UnimplementedGraphServiceServer
    mu          sync.Mutex
    accessToken string
    expiration  time.Time
}

📌 Aqui definimos:

As constantes com os endpoints de autenticação (Entra ID) e do Graph.
Uma struct server que:
- Implementa nosso serviço gRPC.
- Guarda em memória (accessToken, expiration) o último token obtido.

4.2 Gerenciamento de Token

func (s *server) getToken(ctx context.Context) (string, error) {
    s.mu.Lock()
    defer s.mu.Unlock()

    // Se já temos token válido, reutiliza
    if time.Now().Before(s.expiration) && s.accessToken != "" {
        return s.accessToken, nil
    }

    // Senão, pede um novo token ao Entra ID
    tenantID := os.Getenv("ENTRA_TENANT_ID")
    clientID := os.Getenv("ENTRA_CLIENT_ID")
    clientSecret := os.Getenv("ENTRA_CLIENT_SECRET")

    url := fmt.Sprintf(tokenURL, tenantID)
    data := []byte(fmt.Sprintf(
        "client_id=%s&scope=https%%3A%%2F%%2Fgraph.microsoft.com%%2F.default&client_secret=%s&grant_type=client_credentials",
        clientID, clientSecret,
    ))

    req, _ := http.NewRequestWithContext(ctx, "POST", url, bytes.NewBuffer(data))
    req.Header.Set("Content-Type", "application/x-www-form-urlencoded")

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return "", err
    }
    defer resp.Body.Close()

    body, _ := io.ReadAll(resp.Body)
    if resp.StatusCode != http.StatusOK {
        return "", fmt.Errorf("erro ao obter token: %s", string(body))
    }

    var token struct {
        AccessToken string `json:"access_token"`
        ExpiresIn   int    `json:"expires_in"`
    }
    if err := json.Unmarshal(body, &token); err != nil {
        return "", err
    }

    // Atualiza cache (renova 1 min antes do vencimento)
    s.accessToken = token.AccessToken
    s.expiration = time.Now().Add(time.Duration(token.ExpiresIn-60) * time.Second)

    return s.accessToken, nil
}

Explicando

Cache de token: o sidecar não pede token toda hora → economiza requisições.
Mutex (mu): garante que múltiplas chamadas concorrentes não façam POST ao mesmo tempo.
Renovação antecipada: 1 minuto antes de expirar, o sidecar já pede um novo.

4.3 Implementando `GetUser`

func (s *server) GetUser(ctx context.Context, req *pb.UserRequest) (*pb.UserResponse, error) {
    // 1. Garantir token válido
    token, err := s.getToken(ctx)
    if err != nil {
        return nil, err
    }

    // 2. Montar endpoint
    userEndpoint := "me"
    if req.UserId != "" {
        userEndpoint = "users/" + req.UserId
    }

    url := fmt.Sprintf(graphURL, userEndpoint)
    httpReq, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
    httpReq.Header.Set("Authorization", "Bearer "+token)

    // 3. Fazer requisição ao Microsoft Graph
    resp, err := http.DefaultClient.Do(httpReq)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    body, _ := io.ReadAll(resp.Body)
    if resp.StatusCode != http.StatusOK {
        return nil, fmt.Errorf("erro ao buscar usuário: %s", string(body))
    }

    // 4. Mapear resposta para nosso UserResponse
    var user map[string]interface{}
    if err := json.Unmarshal(body, &user); err != nil {
        return nil, err
    }

    return &pb.UserResponse{
        Id:                user["id"].(string),
        DisplayName:       user["displayName"].(string),
        GivenName:         user["givenName"].(string),
        Surname:           user["surname"].(string),
        UserPrincipalName: user["userPrincipalName"].(string),
    }, nil
}

Explicando

Pega o token em cache (ou renova).
Define o endpoint (/me ou /users/{id}).
Faz um GET no Microsoft Graph.
Converte a resposta JSON para a struct UserResponse.

4.4 Subindo o servidor gRPC

func main() {
    lis, err := net.Listen("tcp", ":50051")
    if err != nil {
        panic(err)
    }
    grpcServer := grpc.NewServer()
    pb.RegisterGraphServiceServer(grpcServer, &server{})
    fmt.Println("Sidecar Microsoft Graph rodando em :50051")
    if err := grpcServer.Serve(lis); err != nil {
        panic(err)
    }
}

Explicando

O sidecar ouve na porta 50051.
Ele registra o serviço GraphService.
Ele fica rodando, pronto para responder às chamadas gRPC da aplicação principal.

5. Executando

Configure variáveis de ambiente:

   export ENTRA_CLIENT_ID="seu-client-id"
   export ENTRA_CLIENT_SECRET="seu-client-secret"
   export ENTRA_TENANT_ID="seu-tenant-id"

Rode o sidecar:

   go run sidecar.go

Teste com grpcurl:

   grpcurl -plaintext -d '{}' localhost:50051 graph.GraphService/GetUser

6. Exemplo de resposta

{
  "id": "1234abcd-...",
  "display_name": "João Silva",
  "given_name": "João",
  "surname": "Silva",
  "user_principal_name": "joao@empresa.com"
}

7. Por que usar Sidecar?

Simplicidade: a aplicação só chama gRPC, sem se preocupar com OAuth2.
Reuso: múltiplos serviços podem compartilhar o mesmo sidecar.
Segurança: credenciais ficam apenas no sidecar.
Escalabilidade: sidecars podem ser replicados em pods diferentes.
Observabilidade: métricas e logs podem ser centralizados no sidecar.

Conclusão

Criamos um sidecar em Go que:

Autentica no Microsoft Entra ID via Client Credentials Flow.
Usa o Microsoft Graph para consultar usuários.
Exponde um serviço gRPC simples para a aplicação principal.

Com isso, conseguimos um design mais limpo, seguro e escalável, separando responsabilidades e aproveitando os benefícios do padrão Sidecar.

💡Curtiu?

Se quiser trocar ideia sobre IA, cloud e arquitetura, me segue nas redes:

Redes Sociais

Publico conteúdos técnicos direto do campo de batalha. E quando descubro uma ferramenta que economiza tempo e resolve bem, como essa, você fica sabendo também.