DEV Community: Gabrielle Eduarda

Resilient APIs: How to Build Failure-Tolerant Backends in .NET and AWS

Gabrielle Eduarda — Sun, 02 Nov 2025 18:53:51 +0000

In modern distributed systems, failure is not an exception — it’s a certainty.
APIs depend on databases, caches, message brokers, external services, and networks that fail unpredictably.

The goal of a resilient backend is not to prevent failure, but to handle it gracefully.
In .NET systems running on AWS, resilience means designing APIs that continue to operate reliably, even when parts of the system degrade or become temporarily unavailable.

Understanding Resilience

Resilience is the ability of a system to recover from transient faults and continue functioning correctly.
While reliability focuses on uptime, resilience focuses on response under stress — what your API does when things go wrong.

Key principles of resilience include:

Isolation: preventing one failure from cascading through the system.

Retry logic: automatically recovering from transient errors.

Fallbacks: providing limited functionality when dependencies fail.

Timeouts: preventing calls from hanging indefinitely.

Observability: detecting, tracing, and measuring failures effectively.

Handling Transient Faults with Polly

In .NET, the most effective tool for implementing resilience policies is Polly — a lightweight fault-handling library that supports retries, circuit breakers, and timeouts.

Example: retrying transient AWS API failures.

var retryPolicy = Policy
.Handle()
.OrResult(r => !r.IsSuccessStatusCode)
.WaitAndRetryAsync(3, retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)));

var response = await retryPolicy.ExecuteAsync(() =>
_httpClient.GetAsync("https://api.amazonaws.com/resource"));

This retry pattern uses exponential backoff, giving remote systems time to recover without overloading them.

Applying Circuit Breakers

A circuit breaker prevents your API from continuously calling a failing service.
Once the failure threshold is reached, the circuit “opens” and short-circuits further calls for a cooldown period.

var circuitBreaker = Policy
.Handle()
.CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));

await circuitBreaker.ExecuteAsync(() => CallExternalServiceAsync());

This pattern stops failures from snowballing, protecting your application from resource exhaustion and preserving capacity for healthy operations.

Setting Timeouts and Bulkheads

Timeouts ensure that slow dependencies don’t block threads indefinitely:

var timeoutPolicy = Policy.TimeoutAsync(3);

Meanwhile, bulkheads limit the number of concurrent requests to specific components, preventing one overloaded dependency from starving the rest of the system.

var bulkhead = Policy.BulkheadAsync(10, int.MaxValue);

These two patterns work together to isolate faults and protect the stability of the entire API.

Using AWS Services for Resilience

AWS provides native capabilities to enhance resilience:

Amazon SQS: decouple communication between services and absorb traffic spikes.

Amazon SNS: publish notifications asynchronously instead of blocking API responses.

AWS Lambda + EventBridge: offload heavy or slow operations from synchronous API calls.

Amazon DynamoDB or ElastiCache: use caching and distributed data access patterns to reduce latency.

AWS CloudWatch + X-Ray: detect, trace, and visualize failures across the stack.

The best designs combine software-level resilience (like Polly) with AWS-level resilience (like queues, retries, and scaling policies).

Graceful Degradation and Fallbacks

When a dependency fails, returning a default or cached response is often better than failing entirely.

var fallback = Policy
.Handle()
.FallbackAsync(new HttpResponseMessage(HttpStatusCode.OK)
{
Content = new StringContent("{\"status\": \"cached data\"}")
});

This approach improves user experience, reduces error noise, and prevents full outages when dependencies go offline temporarily.

Observability and Chaos Testing

You cannot achieve resilience without visibility.
Monitoring, tracing, and alerting are non-negotiable.

Use AWS CloudWatch and X-Ray for logs, metrics, and traces.

Add structured logging with correlation IDs in .NET.

Continuously test resilience with chaos engineering tools (e.g., injecting latency, throttling requests).

Observability closes the loop — it tells you why a failure happened and whether your fallback strategies worked as intended.

Building a Resilience Mindset

Resilience is not just code — it’s a culture.
Teams that build resilient APIs share a few common habits:

They expect failure, not fear it.

They treat every dependency as unreliable.

They prioritize degradation over downtime.

They test for worst-case scenarios before they happen in production.

In practice, resilience means trading small, controlled failures for large, uncontrolled ones.

Conclusion

In backend engineering, perfection is not achievable — but resilience is.
By designing APIs that can fail gracefully, you transform downtime into recovery time and uncertainty into confidence.

In .NET and AWS ecosystems, building resilience is not just about using Polly or queues; it’s about adopting a mindset of defensive design.
When failures become part of your plan, your systems — and your teams — move from fragile to truly fault-tolerant.

The Hidden Cost of Microservices: When Complexity Kills Velocity

Gabrielle Eduarda — Sun, 02 Nov 2025 18:49:13 +0000

Microservices have been celebrated as the ultimate architecture for scalability and independence.
They promise faster delivery, team autonomy, and effortless scaling.

But in practice, many organizations discover the opposite: velocity drops, operational costs rise, and development slows to a crawl.
The problem isn’t the concept of microservices itself — it’s when teams adopt them too early or without discipline.

The Myth of Infinite Scalability

The original idea behind microservices was elegant — split a system into small, independent services that can evolve, deploy, and scale separately.
In theory, this allows teams to move faster and avoid coordination overhead.

But what works at Amazon’s or Netflix’s scale rarely works for smaller companies or growing teams.
Microservices shift complexity from code to infrastructure.
Instead of one codebase to manage, you now have dozens — each with its own deployments, monitoring, database migrations, authentication logic, and network failures.

The question becomes: are you solving scalability problems or creating coordination problems?

The Real Cost of Microservices

Operational Overhead

Each microservice needs:

Its own CI/CD pipeline

Monitoring and alerting configuration

Cloud infrastructure (ECS, Lambda, databases, networking)

Deployment strategies and rollback mechanisms

This adds up quickly. A team of five engineers can easily spend more time maintaining pipelines and debugging network issues than building new features.

Distributed Debugging

In a monolith, a stack trace tells you exactly what happened.
In a microservices ecosystem, a single user request may traverse 10 different services, queues, and asynchronous events.

Without robust distributed tracing, debugging becomes guesswork.
Observability tools like OpenTelemetry, X-Ray, or Datadog help — but they add even more layers of setup and maintenance.

Data Fragmentation

Every service owning its own database sounds great — until you need a consistent view of data across the system.
Cross-service joins become API calls. Reporting becomes a data engineering challenge.

Many teams end up creating “reporting microservices” just to re-aggregate data they once had in a single table.

Latency and Reliability

More network hops mean more failure points.
Retries, circuit breakers, and backpressure become mandatory.
Even if each service is “99.9%” reliable, the end-to-end success rate across 20 services might drop below 98%.

The more you distribute your system, the more you must invest in resilience patterns — often reinventing solutions that a single, well-structured monolith could handle naturally.

When Microservices Make Sense

Microservices aren’t bad — they’re just expensive.
They make sense when:

Teams are large enough to maintain independent services.

Domains are clearly defined and stable.

You already have mature DevOps and observability practices.

You’re solving scale or organizational bottlenecks, not creating them.

At that point, the cost is justified.
But adopting microservices before reaching that level of maturity usually reduces delivery speed rather than increasing it.

The Case for Modular Monoliths

A modular monolith often offers the best of both worlds:

One deployable unit, one CI/CD pipeline.

Clear domain separation through internal modules.

Shared logging, authentication, and configuration.

Easy refactoring — extract modules into services only when necessary.

Instead of starting with microservices and struggling to keep them coordinated, you can start modular — and split by evolution, not by design fantasy.

This approach lets architecture grow naturally, in response to real scaling demands rather than imagined ones.

Lessons Learned

Complexity always exists — you can’t remove it, only choose where to put it.
Microservices move it from the codebase into infrastructure and operations.

Small teams need focus, not fragmentation.
Each new service increases cognitive load and reduces collaboration efficiency.

Velocity is not the number of services deployed — it’s how quickly a team can deliver business value.

Start with clarity, not distribution.
Build modular systems first, then split them when the boundaries are clear and justified.

Conclusion

Microservices are powerful, but power without purpose is waste.
They are not a productivity shortcut — they are a trade-off that must be earned through maturity and discipline.

If your system doesn’t yet demand that level of distribution, a well-architected modular monolith will take you further, faster, and with far fewer moving parts.

The goal of architecture is not to look modern — it’s to enable teams to deliver value consistently and confidently.
And sometimes, the fastest way to move forward is to simplify, not split.

The Role of Observability in Modern Backends with .NET and AWS

Gabrielle Eduarda — Sun, 02 Nov 2025 18:44:49 +0000

Modern backend systems are more complex than ever.
Distributed architectures, asynchronous processes, and event-driven workflows have made one principle indispensable: observability.

Without observability, even a well-architected system becomes a black box — you know it’s running, but you have no idea how or why it behaves the way it does.

In .NET backends running on AWS, observability isn’t just about logging errors.
It’s about gaining context — understanding requests, dependencies, latency, and user impact across the entire system.

What Observability Really Means

Observability is often confused with monitoring, but the two are not the same.

Monitoring tells you when something is wrong.

Observability helps you understand why it’s wrong.

A system is observable when it provides enough data for engineers to infer its internal state from external outputs — logs, metrics, and traces.

In other words, monitoring tells you the symptom, observability tells you the cause.

The Three Pillars of Observability

Observability in backend systems relies on three core pillars:

Logs – Detailed event records that describe what happened and where.

Metrics – Aggregated numerical data that reflect system performance (CPU, latency, throughput).

Traces – End-to-end request flows that show how a single operation moves through multiple components or services.

Together, they create a full picture of system behavior.

Why Observability Matters in .NET Systems

A modern .NET backend is often composed of multiple services, background jobs, message queues, and databases.
Without structured observability, diagnosing a single issue could take hours.

Key benefits include:

Faster debugging: quickly identify which component failed and why.

Performance optimization: discover bottlenecks through latency analysis.

User experience improvement: correlate application behavior with customer impact.

Proactive alerting: detect anomalies before they become outages.

Operational confidence: deploy faster with visibility into production health.

Implementing Observability in .NET Backends

Structured Logging

Start by using structured logs instead of plain text.
Libraries like Serilog or Microsoft.Extensions.Logging make it easy to emit JSON logs enriched with context (request IDs, user IDs, correlation IDs).

Log.ForContext("RequestId", context.TraceIdentifier)
.ForContext("UserId", userId)
.Information("Processing order {@Order}", order);

Send these logs to AWS CloudWatch Logs, OpenSearch, or a third-party aggregator like Datadog or New Relic.

Metrics and Application Insights

Use AWS CloudWatch Metrics or Azure Application Insights (if multi-cloud) to track key performance indicators:

Request rate (requests/sec)

Error rate (5xx count)

Average latency

Database query times

Queue processing time

For .NET, the System.Diagnostics.Metrics API provides native support for custom metrics:

using System.Diagnostics.Metrics;

var meter = new Meter("MyApp.Metrics");
var requestCounter = meter.CreateCounter("requests_total");

requestCounter.Add(1);

Publish metrics to CloudWatch using the AWS SDK or OpenTelemetry exporters.

Distributed Tracing

Distributed tracing links every request and operation across services.
With AWS X-Ray or OpenTelemetry, you can visualize end-to-end request paths in .NET applications.

builder.Services.AddOpenTelemetry()
.WithTracing(t => t
.AddAspNetCoreInstrumentation()
.AddHttpClientInstrumentation()
.AddAWSInstrumentation()
.AddXRayExporter());

Traces reveal how much time each component contributes to the total latency and where bottlenecks occur.

Correlation and Context

Always propagate correlation IDs between modules and services.
This allows logs, metrics, and traces to be tied together for a single request, making debugging exponentially easier.

using System.Diagnostics;

var activity = new Activity("ProcessOrder").Start();
activity.AddTag("OrderId", order.Id);
activity.AddTag("UserId", userId);

Observability in AWS

AWS provides a mature ecosystem for observability:

Amazon CloudWatch – unified metrics, logs, and alarms

AWS X-Ray – distributed tracing and visualization

Amazon OpenSearch Service – full-text search and analysis

AWS Distro for OpenTelemetry (ADOT) – open standard instrumentation

AWS CloudTrail – auditing and API-level visibility

Combining these services gives developers deep insight into both application behavior and infrastructure health.

Building an Observability-Ready Architecture

In a production-grade .NET backend running on AWS ECS, a good observability strategy includes:

Centralized logging through CloudWatch or OpenSearch

Distributed tracing via X-Ray or OpenTelemetry

Custom business metrics exported to CloudWatch

Alerting rules (error rate, latency, memory usage)

Dashboards tracking SLA and throughput

Observability is not an afterthought — it should be part of the CI/CD pipeline, enforced through standards and reviewed in every code change.

Evolving from Monitoring to Insight

Traditional monitoring answers the question “Is the system up?”
Observability answers “Why is the system behaving this way?”

A backend that is observable can:

Detect anomalies before users report them

Reduce MTTR (mean time to recovery)

Empower developers to deploy with confidence

Support continuous improvement through real data

For .NET and AWS developers, observability is the foundation of reliable, resilient, and scalable backend systems.

Conclusion

Observability is not a tool — it’s a mindset.
It’s about designing systems that explain themselves, where data replaces assumptions and visibility drives decisions.

When implemented correctly in a .NET backend running on AWS, observability becomes more than diagnostics — it becomes an engineering advantage.

You can’t manage what you can’t see, and you can’t scale what you can’t understand.
Observability gives you both.

Integrating Amazon SES into a .NET Backend Using Clean Architecture

Gabrielle Eduarda — Sun, 02 Nov 2025 18:40:41 +0000

Why Clean Architecture Matters

Clean Architecture is a design philosophy introduced by Robert C. Martin (Uncle Bob) that enforces strict separation between the core business logic and external dependencies.

It is built on three key ideas:

Independence from frameworks – business logic should not depend on frameworks or libraries.

Testability – core logic should be testable without infrastructure.

Separation of concerns – code should be organized around behavior, not technology.

In practice, this leads to four main layers:

/src
├── Domain // Entities, Value Objects, Business Rules
├── Application // Use Cases, Interfaces, DTOs
├── Infrastructure // Database, Email, External APIs
└── WebApi // Controllers, Dependency Injection

Each layer depends only on the layers inside it, never outward.

Understanding Amazon SES

Amazon Simple Email Service (SES) is a cloud-based email sending service that provides:

High deliverability and scalability

API and SMTP interfaces

SPF, DKIM, and DMARC authentication

Cost-effective pricing ($0.10 per 1,000 emails)

In a Clean Architecture project, SES belongs to the Infrastructure layer, not the Application or Domain layer.
The business logic should know what to do (send an email), not how it’s done.

Step 1: Define the Abstraction in the Application Layer

The Application layer defines contracts — interfaces that describe what needs to be done without specifying the implementation.

Create an interface for sending emails:

namespace Application.Common.Interfaces
{
public interface IEmailSender
{
Task SendAsync(string to, string subject, string body, bool isHtml = true);
}
}

This abstraction allows the Application layer to send emails without knowing that SES exists.

Step 2: Implement the Service in the Infrastructure Layer

In the Infrastructure layer, we create the actual SES integration using the AWS SDK for .NET.

using Amazon.SimpleEmail;
using Amazon.SimpleEmail.Model;
using Application.Common.Interfaces;

namespace Infrastructure.Email
{
public class SesEmailSender : IEmailSender
{
private readonly IAmazonSimpleEmailService _sesClient;
private readonly string _fromAddress;

    public SesEmailSender(IAmazonSimpleEmailService sesClient, string fromAddress)
    {
        _sesClient = sesClient;
        _fromAddress = fromAddress;
    }

    public async Task SendAsync(string to, string subject, string body, bool isHtml = true)
    {
        var request = new SendEmailRequest
        {
            Source = _fromAddress,
            Destination = new Destination
            {
                ToAddresses = new List<string> { to }
            },
            Message = new Message
            {
                Subject = new Content(subject),
                Body = new Body
                {
                    Html = isHtml ? new Content(body) : null,
                    Text = isHtml ? null : new Content(body)
                }
            }
        };

        await _sesClient.SendEmailAsync(request);
    }
}

}

This class uses dependency injection to receive the SES client and configuration.

Step 3: Register the Implementation in Dependency Injection

In the WebApi or composition root, configure the dependencies:

using Amazon.SimpleEmail;
using Application.Common.Interfaces;
using Infrastructure.Email;

builder.Services.AddAWSService();
builder.Services.AddSingleton(sp =>
{
var sesClient = sp.GetRequiredService();
var config = sp.GetRequiredService();
var fromAddress = config["Email:From"];
return new SesEmailSender(sesClient, fromAddress);
});

Now any part of the system can use IEmailSender through DI, without referencing SES or AWS directly.

Step 4: Use the Abstraction in an Application Use Case

Inside the Application layer, you can use the IEmailSender in your use cases:

using Application.Common.Interfaces;

namespace Application.Users.Commands
{
public class SendWelcomeEmail
{
private readonly IEmailSender _emailSender;

    public SendWelcomeEmail(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }

    public async Task ExecuteAsync(string userEmail, string userName)
    {
        var subject = "Welcome to our platform!";
        var body = $"<p>Hello {userName},</p><p>We’re excited to have you onboard.</p>";

        await _emailSender.SendAsync(userEmail, subject, body);
    }
}

}

This use case can be tested without SES, because you can mock the IEmailSender interface.

Step 5: Testing Without AWS

To make the Application layer fully testable, you can use a mock implementation:

public class FakeEmailSender : IEmailSender
{
public List<(string To, string Subject, string Body)> SentEmails { get; } = new();

public Task SendAsync(string to, string subject, string body, bool isHtml = true)
{
    SentEmails.Add((to, subject, body));
    return Task.CompletedTask;
}

}

Now your unit tests can verify that the correct email logic was executed without touching AWS.

Step 6: Monitoring and Observability

When running in production, integrate SES with AWS observability tools:

CloudWatch Metrics: monitor send rates, bounces, and complaints.

SNS Notifications: get real-time feedback for delivery events.

CloudTrail: track API calls for auditing and compliance.

SES supports automatic reputation management and DKIM authentication, reducing the risk of your emails being flagged as spam.

Benefits of This Approach

By integrating SES through Clean Architecture, you achieve:

Low coupling: business logic is not tied to AWS.

Testability: easy to mock and verify in unit tests.

Flexibility: switch to another provider (SendGrid, Mailgun) with minimal changes.

Maintainability: infrastructure logic is centralized and isolated.

Scalability: SES can handle millions of emails per day without additional configuration.

Conclusion

Integrating Amazon SES into a .NET backend using Clean Architecture ensures that email functionality remains modular, testable, and future-proof.

Your business rules never depend on cloud SDKs or third-party services.
Instead, they depend on stable, well-defined contracts that make your system easier to evolve and maintain.

Clean Architecture isn’t just about layers — it’s about clarity, independence, and long-term reliability.
With Amazon SES as your email infrastructure and .NET as your foundation, you can build backend systems that scale cleanly and deliver with confidence.

Amazon SES: Reliable, Scalable, and Cost-Efficient Email Delivery for Modern Applications

Gabrielle Eduarda — Sun, 02 Nov 2025 18:37:42 +0000

What is Amazon SES

Amazon SES (Simple Email Service) is a fully managed cloud-based email sending service designed for transactional, notification, and marketing messages.

It provides high deliverability and global scalability without requiring teams to manage SMTP servers, IP reputation, or spam compliance manually.

SES is built on top of Amazon’s email infrastructure, the same system that powers large-scale services like Amazon.com itself.

Core Capabilities

Amazon SES offers all the essential features of a professional-grade email delivery platform:

Flexible Sending Options

SMTP Interface: Compatible with any email library or client that supports SMTP.

API Access: Direct integration via the AWS SDK or HTTPS requests for higher performance and security.

Templated Emails: Predefined layouts stored and managed directly in SES.

Deliverability Management

Built-in DKIM, SPF, and DMARC authentication support.

Automatic IP warm-up to build sender reputation gradually.

Feedback loops and bounce notifications through Amazon SNS.

Scalability and Throughput

Automatically scales to millions of emails per day.

Supports high throughput for transactional and bulk campaigns.

Works seamlessly with AWS regions around the world to reduce latency.

Monitoring and Analytics

Amazon CloudWatch integration for delivery metrics, bounce rates, and complaints.

Event publishing to Amazon Kinesis or Amazon S3 for custom analytics and dashboards.

Security and Compliance

Fine-grained IAM permissions to control which users or applications can send emails.

VPC endpoints for secure private connectivity.

Compliance with industry standards and regional regulations (e.g., GDPR, CAN-SPAM).

Pricing Model

One of the most attractive aspects of SES is its pricing structure.
You only pay for what you send:

Feature Price
Outgoing email $0.10 per 1,000 emails
Data transfer (attachments) $0.12 per GB
Incoming email (optional) $0.10 per 1,000 emails
Dedicated IPs (optional) $24.95 per month per IP

If your application is hosted on Amazon EC2, you can send up to 62,000 emails per month for free.

This makes SES one of the most cost-efficient enterprise-grade email solutions on the market.

Integration Options

Amazon SES can be integrated in several ways, depending on your architecture and development stack:

Direct API Integration:
Using the AWS SDK for .NET, Python, Node.js, or Java to send emails programmatically.

SMTP Relay:
Configure your application or email client with SMTP credentials generated in the AWS Console.

Infrastructure Integrations:

Combine with Amazon S3 to store sent or received emails.

Use Amazon SNS for real-time delivery notifications.

Stream metrics to Amazon CloudWatch or Kinesis Data Firehose for analytics.

Serverless Workflows:

Trigger emails from AWS Lambda or EventBridge for fully event-driven delivery.

Example: Sending Email Using AWS SDK for .NET
using Amazon.SimpleEmail;
using Amazon.SimpleEmail.Model;

public class EmailService
{
private readonly IAmazonSimpleEmailService _sesClient;
private readonly string _fromAddress = "noreply@yourdomain.com";

public EmailService(IAmazonSimpleEmailService sesClient)
{
    _sesClient = sesClient;
}

public async Task SendAsync(string to, string subject, string htmlBody)
{
    var sendRequest = new SendEmailRequest
    {
        Source = _fromAddress,
        Destination = new Destination { ToAddresses = new List<string> { to } },
        Message = new Message
        {
            Subject = new Content(subject),
            Body = new Body { Html = new Content(htmlBody) }
        }
    };

    await _sesClient.SendEmailAsync(sendRequest);
}

}

This simple implementation can easily be adapted to any architecture, from monolithic applications to serverless or microservice environments.

Deliverability Best Practices

To achieve consistent inbox placement and avoid spam filtering:

Verify domains and sender emails before sending.

Implement SPF, DKIM, and DMARC records in your DNS.

Use production mode after testing in the sandbox environment.

Monitor bounce and complaint rates with SNS and CloudWatch.

Warm up new IPs gradually when sending large volumes.

Keep email content clean, personalized, and compliant with anti-spam laws.

Following these guidelines ensures strong sender reputation and long-term deliverability.

When to Use Amazon SES

Amazon SES is ideal for:

SaaS platforms sending transactional or verification emails

Internal systems needing reliable notifications (e.g., alerts, reports)

Applications migrating from self-managed SMTP servers

Developers who need scalable, cost-effective email delivery tightly integrated with AWS infrastructure

For most backend workloads — especially those already using AWS — SES provides the best balance between cost, reliability, and control.

Conclusion

Amazon SES is not just an email API — it is a complete, enterprise-grade email delivery infrastructure.
It removes the complexity of managing servers, DNS authentication, reputation monitoring, and scaling logic.

By integrating SES correctly, teams can send millions of emails per day with high deliverability, complete observability, and minimal operational overhead.

For applications running on AWS — whether monolithic, modular, or serverless — SES remains one of the most effective and affordable communication components available today.

Modular Monoliths on AWS: Simplicity, Structure, and Scalability

Gabrielle Eduarda — Sun, 02 Nov 2025 18:34:40 +0000

Why Modular Monoliths Work So Well on AWS

AWS is designed to support large-scale distributed architectures — but that doesn’t mean every system should start that way.
For small and medium-sized platforms, a modular monolith provides several benefits within AWS:

Simplicity: A single deployable artifact simplifies ECS, EC2, or Lambda deployment pipelines.

Observability: Centralized logging, tracing, and metrics are easier to manage through CloudWatch and X-Ray.

Security: IAM policies can secure the entire workload without needing to coordinate dozens of microservices.

Cost efficiency: You pay for fewer running containers or instances.

Evolution: When scale demands it, modules can be extracted into separate services without redesigning the entire system.

In short, AWS gives you the tools to scale; a modular monolith lets you delay complexity until it’s truly necessary.

Architecture Overview

A typical modular monolith on AWS might follow this structure:

Application: A .NET API containing multiple business modules (e.g., Patients, Professionals, Billing, Identity).

Infrastructure as Code: Defined through Terraform, AWS CDK, or SST to manage all resources.

Runtime Environment:

Amazon ECS with Fargate for container orchestration

Elastic Load Balancer (ALB) for traffic distribution

AWS Secrets Manager for storing credentials and configuration

Data Layer:

Amazon RDS (PostgreSQL or SQL Server) for relational persistence

Optional Amazon S3 for object storage

Communication and Events:

Internal modules communicate in-process

External integrations use SQS or EventBridge for asynchronous messaging

CI/CD:

GitHub Actions or AWS CodePipeline builds, tests, and deploys a single container image

Monitoring:

CloudWatch Logs for application and infrastructure logs

AWS X-Ray for tracing request flow through modules

This setup keeps the infrastructure lightweight while supporting high availability and autoscaling.

Example: Deploying a .NET Modular Monolith on ECS Fargate

Build and containerize the app:

docker build -t myapp:latest .
docker tag myapp:latest .dkr.ecr.us-east-1.amazonaws.com/myapp:latest
docker push .dkr.ecr.us-east-1.amazonaws.com/myapp:latest

Provision AWS resources (simplified example using Terraform):

resource "aws_ecs_cluster" "app_cluster" {
name = "modular-monolith-cluster"
}

resource "aws_ecs_task_definition" "app_task" {
family = "myapp"
network_mode = "awsvpc"
requires_compatibilities = ["FARGATE"]
cpu = "512"
memory = "1024"
container_definitions = jsonencode([{
name = "myapp"
image = ".dkr.ecr.us-east-1.amazonaws.com/myapp:latest"
portMappings = [{ containerPort = 80 }]
}])
}

resource "aws_ecs_service" "app_service" {
name = "myapp-service"
cluster = aws_ecs_cluster.app_cluster.id
task_definition = aws_ecs_task_definition.app_task.arn
desired_count = 2
launch_type = "FARGATE"
network_configuration {
subnets = var.private_subnets
security_groups = [aws_security_group.app_sg.id]
}
load_balancer {
target_group_arn = aws_lb_target_group.app_tg.arn
container_name = "myapp"
container_port = 80
}
}

Configure CloudWatch logging and alarms to monitor CPU, memory, and application health.

Enable autoscaling policies so ECS adjusts the number of tasks dynamically based on traffic.

Observability and Operations

Running a modular monolith on AWS doesn’t mean sacrificing visibility.
In fact, it can make observability simpler:

CloudWatch Logs can aggregate logs from all modules.

AWS X-Ray provides detailed traces through different layers of your application.

Amazon CloudWatch Metrics and Alarms let you monitor response times, error rates, and throughput.

AWS OpenTelemetry and Grafana can extend insights into performance at the code level.

Because all modules share the same process, tracing and debugging are more direct and coherent than across multiple services.

Integrating AWS Services into a Modular Monolith

A modular monolith still benefits from AWS’s extensive ecosystem. Examples include:

Email and Notifications: Use Amazon SES or SNS through clean abstractions.

File Management: Store files or reports in Amazon S3, referenced by module identifiers.

Caching: Use Amazon ElastiCache (Redis) for performance and session storage.

Background Jobs: Use Amazon SQS or AWS Lambda triggered from internal modules for asynchronous processing.

Each integration should live inside the Infrastructure layer of your modules, keeping the domain logic independent from AWS SDKs or configurations.

Evolution: From Modular Monolith to Microservices

When certain modules outgrow the main application — for instance, if a Payment or Reporting module begins to demand independent scaling — they can be extracted into standalone services.

This transition is straightforward because:

The boundaries are already defined.

Communication contracts already exist.

Infrastructure patterns (build, deploy, monitor) are established in AWS.

A modular monolith allows a gradual, risk-free migration to microservices when needed, rather than a full rewrite.

Conclusion

Deploying a modular monolith on AWS combines the operational simplicity of a monolith with the architectural discipline of microservices.
It offers:

Clear separation of business domains

Easier testing and deployment

Lower operational cost and maintenance effort

A smooth path to distributed architecture when scale requires it

Good architecture is not defined by how many services you have, but by how cleanly your system evolves.
On AWS, a modular monolith is often the most effective way to start — simple to operate, structured to grow, and ready to scale when the time comes.

Modular Monoliths: Building Scalable Systems Without Unnecessary Complexity

Gabrielle Eduarda — Sun, 02 Nov 2025 18:32:15 +0000

What is a Modular Monolith?

A modular monolith is a single deployable application whose internal structure is divided into independent modules, each representing a specific business domain or bounded context.

Unlike a traditional monolith, where code from different areas is intertwined, a modular monolith clearly separates domains and enforces boundaries through explicit contracts and dependency rules.

Each module encapsulates its own business rules and data access, following the principles of high cohesion and low coupling. The result is a system that behaves like a monolith operationally but maintains many of the structural advantages of a microservice architecture.

Why Modular Monoliths Matter

The modular monolith pattern addresses common pain points of large codebases:

Isolation: Changes in one domain do not ripple across unrelated parts of the system.

Clarity: Code is organized around business capabilities, not technical layers.

Maintainability: Each module can evolve with minimal impact on others.

Performance: Modules communicate in-process, eliminating the latency and complexity of network calls.

Operational simplicity: One deployable artifact means simpler CI/CD, monitoring, and rollback strategies.

Rather than adding network boundaries too early, a modular monolith keeps the architecture clean and cohesive while avoiding premature distribution.

Core Principles of a Modular Monolith

A successful modular monolith typically follows a few key architectural guidelines:

Clear Domain Boundaries

Each module represents a bounded context. It contains everything related to that business area: entities, use cases, repositories, and interfaces.

Dependency Direction

Modules do not depend on each other directly. If interaction is necessary, they communicate through well-defined interfaces registered in a composition root or dependency injection container.

Encapsulation

Internal details of a module are private. Only public contracts are exposed to the rest of the system.

Independent Testing

Each module can be tested in isolation, both at the domain and application level.

Controlled Growth

If a module grows large enough, it can later be extracted as a standalone service with minimal friction.

Example: Structuring a Modular Monolith in .NET

A practical organization might look like this:

/src
├── Modules
│ ├── Patients
│ │ ├── Domain
│ │ ├── Application
│ │ ├── Infrastructure
│ │ └── PatientsModule.cs
│ ├── Professionals
│ │ ├── Domain
│ │ ├── Application
│ │ ├── Infrastructure
│ │ └── ProfessionalsModule.cs
│ └── Identity
│ ├── Domain
│ ├── Application
│ ├── Infrastructure
│ └── IdentityModule.cs
└── WebApi
├── Program.cs
└── CompositionRoot.cs

This layout allows each domain to remain internally consistent while still part of a single deployable system. The Web API acts as the entry point, wiring dependencies and exposing endpoints.

Communication Between Modules

In a modular monolith, modules depend on contracts, not implementations.
For example, the Patients module might need to query information from the Professionals module:

public interface IProfessionalService
{
Task ExistsAsync(Guid professionalId);
}

The implementation of IProfessionalService resides in the Professionals module and is registered in the application’s dependency injection container.
This keeps both modules loosely coupled and independent of one another.

When to Choose a Modular Monolith

A modular monolith is a strong fit when:

Your product is in early or medium growth stages.

Your team is small to medium-sized.

You want fast delivery cycles without distributed system complexity.

You plan to evolve toward microservices only when truly necessary.

Many successful systems started as modular monoliths before extracting specific modules — authentication, payments, notifications — into independent services once scale demanded it.

Advantages at a Glance
Aspect Modular Monolith Microservices
Deployment Single unit Multiple independent services
Communication In-process (fast) Over network (complex)
Complexity Lower High operational overhead
Modularity Strong internal boundaries Distributed boundaries
Scaling Vertical or selective extraction Horizontal per service
Team requirements Moderate High maturity and coordination
Conclusion

A modular monolith is not a step backward from microservices; it is a disciplined, evolutionary architecture that emphasizes clarity, modularity, and maintainability.

By keeping boundaries explicit and dependencies under control, it enables teams to build software that scales in both complexity and performance — without unnecessary operational overhead.

Good architecture is not defined by how many services you deploy, but by how clearly your system expresses its domains and how easily it can evolve.
The modular monolith strikes that balance perfectly.

Event-Driven Architectures

Gabrielle Eduarda — Wed, 17 Sep 2025 23:13:16 +0000

Why Event-Driven Architecture is Becoming Essential for Scalable Systems

Scalability, flexibility, and real-time responsiveness are no longer “nice-to-have” features. Modern applications must handle unpredictable spikes, integrate with multiple services, and remain resilient under pressure. Event-Driven Architecture (EDA) has quickly become a foundational pattern to achieve this.

Unlike traditional request-response systems, EDA embraces asynchronous communication. Services publish events without needing to know who consumes them, and consumers react at their own pace. This decoupling makes systems easier to evolve over time.

Think about an e-commerce platform: when an order is placed, it triggers events such as OrderCreated, InventoryReserved, or PaymentProcessed. Instead of one service calling another directly, each service simply reacts to events relevant to its domain. This reduces dependencies and avoids bottlenecks.

Scalability is one of the strongest benefits. Message brokers like Kafka, RabbitMQ, or AWS SQS can process millions of messages per second. That level of throughput is difficult to achieve in synchronous APIs.

However, adopting EDA is not without challenges. Governance, schema evolution, and observability become critical. Without proper monitoring, teams risk building a “black box” of invisible flows. Event logs, tracing, and contracts must be treated as first-class citizens.

Another important point is error handling. What happens if an event is consumed twice, or not consumed at all? Designing for idempotency and resilience is essential.

Over time, organizations that master EDA find themselves able to innovate faster. Adding a new consumer is as simple as subscribing to an existing event stream—no need to modify upstream services.

EDA is no longer just for tech giants. It is becoming the default pattern for organizations of all sizes looking to scale responsibly.

How do you envision event-driven systems shaping the next wave of software development?

The Future of Back-End Development in the Age of AI

Gabrielle Eduarda — Tue, 16 Sep 2025 23:40:43 +0000

How AI Impacts the Back-End Developer’s Workflow

A back-end developer’s daily work often includes repetitive, technical tasks such as:

Generating boilerplate code for APIs and services.

Writing basic unit tests.

Setting up repositories, DTOs, and migrations.

Crafting standard SQL queries.

These are perfect candidates for automation.
Generative AI tools can handle such work in seconds, reducing hours of effort.

But here’s the catch: these tasks only scratch the surface of what back-end development really is.

What AI Still Can’t Replace

Back-end development is not just about writing code — it’s about thinking in systems. And that’s where AI still falls short:

Domain modeling
Understanding complex business rules and translating them into entities, use cases, and integrations.

Architecture and scalability
Choosing between microservices, modular monoliths, or hybrid approaches.
Planning for resilience, database sharding, queue partitioning, and distributed caching.

Security and compliance
Protecting sensitive data, designing robust authentication/authorization flows, and meeting regulations like GDPR, LGPD, or PCI.

Critical integrations
Banks, legacy systems, messaging queues, external APIs… each one carries unique risks and requires both business and technical vision.

Decision-making
AI can suggest options, but the trade-offs between cost, risk, time, and organizational context must still be evaluated by humans.

In short: AI executes; developers strategize.

The Skills Back-End Developers Need for the Future

Being a strong coder is no longer enough. The future of back-end development requires broader skills:

Orchestrating humans + AI
Knowing when to rely on AI for acceleration, when to trust it, and when to review carefully.

Cloud and DevOps expertise
Infrastructure as code, CI/CD pipelines, autoscaling, observability, and fault tolerance.

Business awareness
Aligning technical decisions with business outcomes and real-world goals.

Data literacy
Handling large datasets with efficiency, performance, and ethical responsibility.

Soft skills
Communication, collaboration, and critical thinking will be more important than ever.

AI as Co-Pilot, Not Pilot

Think of AI as a co-pilot in an aircraft.
It can calculate routes, automate tasks, and provide suggestions in real time.

But the decision to take off, land, or change course lies with the pilot.
In back-end systems, that pilot is still the developer.

AI will not replace the professional who understands systems end-to-end, aligns with business needs, and can operate under pressure.
Instead, AI will replace the “copy-paste coder” — those who just replicate patterns without deeper understanding.

Conclusion

The future of back-end development is not about competing with AI.
It’s about learning to work alongside it.

Developers who use AI to remove repetitive tasks will gain more time to focus on architecture, innovation, and solving complex problems.
Those who ignore it risk being left behind.

What about you? How do you see this future?
Will AI be a threat or a partner in your back-end career?

Frontend as Engineering: Designing Scalable Systems with Micro Frontends

Gabrielle Eduarda — Tue, 15 Jul 2025 23:59:32 +0000

As frontend applications grow — and multiple teams begin working in parallel — new challenges emerge. Monolithic repositories, tightly coupled modules, and risky deployments become blockers. That’s when frontend must stop being "just UI" and start being treated as an engineering system.

One of the most effective strategies in large-scale frontend architecture is the use of micro frontends. In this article, we’ll break down what they are, when to use them, and how to design a modern, scalable frontend system around them.

What are micro frontends? Micro frontends apply the principles of microservices to the frontend. Instead of one large app, the UI is split into independent modules — each with its own repository, deployment lifecycle, and ownership.

Examples of segmentation:

Authentication module

Analytics dashboard

Admin panel separated from public site

Different teams maintaining different slices of the product

Benefits in enterprise environments

Team scalability: multiple teams work independently without merge conflicts

Isolated deployments: failures in one module don’t break the whole app

Code reuse across products: modules can be shared between multiple applications

Gradual migration: rewrite legacy apps incrementally without stopping the world

Technical strategies for micro frontends

Module Federation (Webpack 5): load remote modules at runtime

Single SPA: orchestrates multiple apps into one cohesive experience

iFrames (in legacy or restricted contexts): sometimes still used for hard isolation

Independent deploys with reverse proxies (e.g., NGINX, AWS CloudFront)

Pitfalls and common risks

Increased complexity if introduced too early

Duplicate dependencies if modules are poorly configured

Fragile inter-app communication if contracts aren't well defined

Performance issues: multiple bundles may slow initial load if not optimized

When not to use micro frontends

Small projects or teams with limited size

Short-lived products or MVPs

Teams lacking maturity in CI/CD, testing, or versioning practices

Conclusion
Micro frontends are not hype — they’re a strategic response to scale. In complex ecosystems with multiple teams and domains, breaking down the frontend into isolated, composable parts makes development, testing, and deployment safer and faster.

It’s not about splitting for the sake of complexity — it’s about splitting to scale.

Cron Jobs in the Frontend?! When It Makes Sense and How to Handle It

Gabrielle Eduarda — Tue, 15 Jul 2025 23:48:59 +0000

When we hear "cron job," we usually think of backend tasks: processing queues, sending reports, or syncing data. But what if we told you there’s a valid case for cron-like behavior on the frontend?

In this article, we’ll explore when it makes sense to run scheduled tasks in frontend applications, how to do it safely, and what patterns or tools can help.

What is a "cron job" in the frontend context? While frontend applications don’t have access to system-level cron like Unix, the concept of recurring or scheduled tasks still applies. For example:

Recurring tasks via setInterval or setTimeout

Scheduling with Service Workers or Background Sync

Triggering periodic updates while the app is open (e.g., polling APIs every X minutes)

Executing logic based on user session timing or local triggers (e.g., session cleanup, data refresh)

When does it make sense to schedule tasks in the frontend? There are legitimate use cases:

Offline-first apps: syncing data when the device regains connectivity

Silent token refresh: periodically renewing authentication tokens

Preloading or refreshing cached content: improving perceived performance

User reminders or engagement prompts: especially in PWAs

In these scenarios, the goal is to improve user experience or data reliability without relying solely on backend events.

But beware: frontend is not reliable for critical automation Frontend environments are inherently unstable: tabs close, devices sleep, browsers throttle inactive windows, and background timers can be paused or skipped entirely. So you can’t rely on them for guaranteed execution.

For example, a setInterval to refresh a token every 15 minutes might not run at all if the tab is inactive or throttled by the browser.

Smarter alternatives: when reliability matters If your task is mission-critical (e.g., submitting offline transactions, syncing sensitive data), consider:

Service Workers + Background Sync API: allows queuing requests to be sent once the user is back online

Local persistence + backend triggers: store actions in local storage or IndexedDB and sync them when the app restarts

Hybrid approach: emit frontend events to a queue system (like AWS SQS or Kafka) and process them reliably on the backend

Use cron logic in the frontend for UX, not for business logic Frontend timers are great for progressive enhancement: auto-refreshing dashboards, cleaning stale cache, or showing "last updated X minutes ago". But if a task has business impact, it should be backed by backend logic.

Conclusion
Frontend-based scheduling isn’t a replacement for backend cron — but it can be a powerful UX and reliability enhancer when used consciously. Know the limits, choose the right tools, and never trust the browser to act like a server. When used right, timed logic in the frontend helps bridge gaps between user behavior, network instability, and real-world constraints.

Why React Still Leads in Complex Frontend Architectures

Gabrielle Eduarda — Tue, 15 Jul 2025 23:45:15 +0000

React is not the newest kid on the block. With frameworks like Svelte, Solid, and even newer versions of Angular gaining traction, it’s fair to ask: why is React still the go-to choice for complex frontend applications in large companies?

The answer lies not only in its simplicity and flexibility, but in the ecosystem that grew around it, the predictability it offers at scale, and how it adapts to evolving architectures like micro frontends and server-side rendering.

A minimal core with maximum flexibility React’s core is intentionally unopinionated. That may be frustrating for beginners, but in large projects, it becomes an asset. Teams can make architectural decisions based on context — not because a framework forces them to follow a single pattern.

You want Redux? Zustand? Context API? Server-side rendering with Next.js? You choose. This flexibility allows React to fit into highly customized pipelines and tech stacks.

The ecosystem is mature and battle-tested React’s community has been solving hard problems for over a decade. Every challenge you’re likely to face — from state management to performance bottlenecks — already has a well-documented solution, an open-source library, and Stack Overflow threads to back it up.

In environments where developer productivity matters, using mature tools and patterns gives a competitive advantage.

Stability matters in enterprise For large organizations, a stable ecosystem is more valuable than rapid innovation. React follows a thoughtful release cycle with clear upgrade paths, which reduces the risk of technical debt introduced by breaking changes.

This is a key reason why banks, e-commerce giants, and enterprise SaaS products often choose React over more experimental or fast-changing frameworks.

Compatibility with modern architecture patterns React plays well with micro frontends, component-driven development, and design systems. Its decoupled nature makes it easy to integrate in multi-team environments where UI modules are developed in parallel.

Tools like Module Federation, Storybook, and design tokens align naturally with React’s component-based approach.

Strong hiring pool and onboarding It’s easier to scale a team when the talent pool is large. React is widely adopted in bootcamps, universities, and online learning platforms. Bringing new developers onboard is faster, and internal knowledge sharing is more efficient.

This lowers the cost of growing or restructuring frontend teams in complex projects.

Conclusion
React’s dominance isn’t about hype anymore — it’s about stability, flexibility, and fit. While it’s important to evaluate new technologies, React has consistently proven it can evolve without losing the qualities that make it a reliable choice for complex frontend architectures.

It’s not always the flashiest tool in the shed, but it’s still one of the most powerful.