DEV Community: Francisco Silvério

Microservices with Bounded Contexts, Event-Driven Operations and Sagas: The Art of Orchestrating a Distributed System

Francisco Silvério — Wed, 18 Feb 2026 13:17:11 +0000

In a monolithic architecture, a transaction is a single, atomic database operation. It either happens in full, or it doesn't happen at all. It’s safe, but it can become a bottleneck when millions of users are trying to process transactions simultaneously. As we scale into distributed systems, we trade that localized safety for a "relay race" across multiple services.

To prevent this relay race from ending in a catastrophe, we must move beyond the basic "microservices" buzzword and master the orchestration between services.

1. The System: International Wire Transfer

This architecture draft draws a microscope to a banking engine, specifically, the part responsible for wire transfers. Its mission is to move funds across borders while satisfying three distinct business requirements:

Integrity: Ensuring the math adds up and funds are accounted for.
Security: Screening every transaction against global watchlists.
Market Accuracy: Locking in volatile currency exchange rates in real-time.

Instead of a single "Banking Service," we have three autonomous "islands" of logic: Ledger (Core), Fraud (Compliance), and FX (Currency).

2. Establishing the concepts

I. Bounded Context: The "Territory" of Data

The term "Bounded Context" was originated by Eric Evans, who defines it as:

A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.

Looking at the diagram, you’ll notice that the Entity: Account exists in all three services, but the Account Model is different in each one. This is the Bounded Context in action.

In the Ledger Context: An account is a Balance Container. It only cares about Available Balance and Currency.
In the Fraud Context: An account is a Legal Risk Profile. It cares about the Owner Legal Name and Watchlist Flags.
In the FX Context: An account is a Regional Wallet. It cares about the Home ISO and the Local Market Rate.

By isolating these models, we ensure that a change in the Compliance department's risk-rating logic never accidentally breaks the code responsible for calculating account balances. Each service owns its own "version of the truth."

II. Event-Driven Operations: The "Nervous System"

In the provided architecture, notice that the services never call each other's APIs directly. They communicate via a Message Bus.

When a request arrives, the Ledger doesn't "tell" Fraud to start a check; it simply announces a fact: TransferRequested.

Decoupling: The Ledger doesn't know (or care) if the Fraud service is currently online. It drops the message on the Bus and continues its work.
Autonomy: The Fraud and FX services are "Subscribers." They react to the message when they have the resources to do so. This prevents a slow-down in one service from cascading into a total system failure.

3. The Saga: Orchestrating the Distributed "Undo"

Now that we have established what the system does and why it is organized this way, one question might pop up: If these services are independent islands, who ensures the process actually finishes?

This is where the Saga Pattern enters.

In a distributed system, there is no "Global Rollback." If the money is locked in the Ledger (Step 2) and the Fraud service emits a SecurityCleared message, but the FX system finds a problem, there is no way to automatically revert all the other database records. We must perform a Compensating Transaction.

How the Saga Orchestrates the System:

The Happy Path:
- Ledger locks the funds emits TransferRequested.
- Fraud clears the user emits SecurityCleared.
- FX locks the conversion rate emits RateLocked.
- Result: The transfer is finalized.
The Failure Path (The "Undo" Button):
- Ledger locks $10,000 and emits TransferRequested.
- Fraud Service checks pass and it emits a SecurityCleared message.
- FX Service fails to process the transaction and emits TransactionNotAllowed.
- The Compensation: The Ledger and Fraud services are "listening" for failure events. Upon hearing TransactionNotAllowed, they trigger their own internal "Undo" logic to unlock the $10,000 and notify the user.

Choreography vs. Orchestration

Our system uses Choreography. There is no central "Boss" or "Orchestrator" service. The Ledger works as an entry point for the operation, but it is not responsible for managing the state of the entire flow.

If we required more granular control over the operation, we could implement Orchestration, where a dedicated service directs the transaction and has the final word to approve or deny it. For many decentralized systems, however, the Choreography shown here offers the best balance of scale and simplicity.

Conclusion: Resilience by Design

By combining Bounded Contexts (to isolate logic), Event-Driven Operations (to decouple communication), and Sagas (to handle failures), we build a system that is far more resilient and performant than any monolith. We accept "Eventual Consistency" in exchange for a system that can scale globally and fail gracefully.

Automating React App deployments to AWS with GitHub Actions and OIDC

Francisco Silvério — Sun, 01 Feb 2026 21:26:37 +0000

After deploying my personal website to AWS, I realized the need to automate the deployment process to streamline the delivery of new features. For that, you can’t go wrong with a CI/CD pipeline powered by your Git provider — in this case, GitHub and GitHub Actions.

In this article, I’ll walk through the architecture and CI/CD pipeline I use to deploy a React application to S3 + CloudFront, authenticated via GitHub Actions OIDC (no long-lived AWS credentials).

This setup is suitable for real-world projects and follows AWS and GitHub best practices.

Architecture Overview

Before diving into CI/CD, let’s clarify the infrastructure that was already in place.

Initial AWS Setup (Pre-requisites)

The following resources were already created before the pipeline was written.

1 - S3 bucket

Static website hosting enabled
Public access configured appropriately
Hosts the built React assets (index.html, /assets/*, etc.)

2 - CloudFront distribution

Origin pointing to the S3 website endpoint
Default root object: index.html
Caching enabled
Custom domain configured

3 - Name.com

Custom domain pointing to the CloudFront distribution

Once this setup is complete, the website can already be accessed via the custom domain.
The CI/CD pipeline’s job is to automate updates safely and consistently.

AWS: Configuring OIDC Authentication

1 - Create an OIDC Identity Provider

In AWS IAM:

Provider URL:

https://token.actions.githubusercontent.com

Audience:

sts.amazonaws.com

This allows AWS to trust GitHub as an identity provider.

2 - Create an IAM Role for GitHub Action

This role will be assumed by the GitHub Actions runner.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:<ORG>/<REPO>:*"
        }
      }
    }
  ]
}

3 - Attach Required IAM Permissions

The role needs permissions to:

Sync files to S3
Create CloudFront invalidations

Example policy (simplified):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::<BUCKET_NAME>",
        "arn:aws:s3:::<BUCKET_NAME>/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "cloudfront:CreateInvalidation",
      "Resource": "*"
    }
  ]
}

GitHub Actions Pipeline Overview

The pipeline is split into three jobs:

install – install dependencies
build – build the React app and upload artifacts
deploy – authenticate to AWS, deploy to S3, invalidate CloudFront

This separation improves clarity, caching, and debuggability.

Job 1: Installing Dependencies

install:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - name: Install dependencies
      uses: actions/setup-node@v4
      with:
        node-version: "22.x"
        cache: 'npm'
    - run: npm ci

What this job does

Checks out the repository
Sets up Node.js 22
Uses npm ci for deterministic installs
Enables dependency caching for faster builds

This job ensures the dependency tree is valid before moving forward.

Job 2: Building the React Application

build:
  runs-on: ubuntu-latest
  needs: install
  steps:
    - uses: actions/checkout@v4
    - name: Use Node.js 22
      uses: actions/setup-node@v4
      with:
        node-version: "22.x"
        cache: 'npm'
    - run: npm ci
    - run: npm run build
    - name: Upload dist
      uses: actions/upload-artifact@v4
      with:
        name: dist
        path: ./dist

What this job does

Rebuilds the application in a clean environment
Produces a static dist/ folder
Uploads the build output as a pipeline artifact

Artifacts allow the deploy job to be fully decoupled from the build process.

Job 3: Deploying to AWS (S3 + CloudFront)

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment: aws
    permissions:
      id-token: write
      contents: read

    steps:
      - name: Download dist artifact
        uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ARN }}
          aws-region: ${{ vars.AWS_REGION }}
          role-session-name: ${{ vars.ROLE_SESSION_NAME}}

      - name: Deploy to S3
        run: |
          aws s3 sync dist s3://${{ vars.S3_BUCKET_NAME }} \
            --delete \
            --exact-timestamps

      - name: Invalidate CloudFront
        run: |
          aws cloudfront create-invalidation \
            --distribution-id ${{ vars.CLOUDFRONT_DISTRIBUTION_ID }} \
            --paths "/*"

What this job does

Downloads the build artifact
Authenticates to AWS
Uploads the static files to the bucket
Invalidate CloudFront's cache

Invalidating /* ensures CloudFront fetches the new version immediately.

Final Result

After every push to main:

The app is built
Assets are uploaded to S3
CloudFront cache is invalidated
The custom domain serves the latest version reliably

All without storing a single AWS secret in GitHub.

References

- GitHub Actions OIDC

- AWS IAM OIDC

- CloudFront invalidations

- aws-actions/configure-aws-credentials