DEV Community: Luis Núñez

AWS Messaging: SQS vs SNS vs EventBridge

Luis Núñez — Sun, 27 Sep 2026 00:25:40 +0000

Hello everyone! Recently, I have been learning a lot about backend architecture and microservices.

When we move from a monolithic application (where if one part fails, the whole system crashes) to microservices, we have a big challenge: How do we make our services communicate without being tightly connected?

AWS gives us three great services for this: Amazon SQS, Amazon SNS, and Amazon EventBridge. At first, they looked very similar to me, but they have very different jobs. Here are my study notes on how to understand them!

1. Amazon SQS: The Buffer (1-to-1 Queue)

Amazon SQS (Simple Queue Service) is a message queue. It saves messages safely until a consumer is ready to process them.

How it works: It uses a Pull model. Your app sends a message to the queue, and a worker asks for the message, processes it, and deletes it.
Easy Analogy: Imagine a tech support waiting line. If 100 people need help at the same time, the IT guy doesn't have to talk to everyone at once. They take a ticket, wait in the queue, and the IT guy helps them one by one at his own speed.
Why it's great: It prevents your system from crashing when you have too much traffic.

2. Amazon SNS: Mass Notifications (1-to-Many Pub/Sub)

Amazon SNS (Simple Notification Service) is a Publish/Subscribe service.

How it works: It uses a Push model. A publisher sends one message to a "Topic", and SNS immediately delivers that message to all subscribers (like emails, SMS, or other queues).
Easy Analogy: Think of it like a megaphone. You shout the news only once, and everybody in the room hears it at the exact same time.
Why it's great: It is perfect for the Fan-out pattern (sending the same event to many different places in parallel).

3. Amazon EventBridge: The Smart Router

Amazon EventBridge is a serverless event bus. It is perfect for Event-Driven Architectures.

How it works: It receives events from your apps, AWS services, or external platforms (like Stripe), looks at the data, and uses rules to decide where to send them.
Easy Analogy: It is like a post office. The worker looks at the address on your package, reads the rules, and decides which truck should take it.
Why it's great: It has advanced filtering. It can read the JSON content of the event and make smart routing decisions.

A Real-World Story: Combining all three

Let's imagine it is a busy Friday night. You are very hungry and you order a pizza using a food delivery app. How do these three services work together behind the scenes?

The Order: You click "Buy". The mobile app sends an OrderPlaced event to Amazon EventBridge.
The Smart Routing: EventBridge looks at the event. Because the payment was successful, its rules decide to send the event to two places: the restaurant and the notification system. It sends the event to an Amazon SNS topic.
The Megaphone: The SNS topic receives the event and shouts: "New order!". It immediately sends a Push notification to your phone ("Your pizza is confirmed!") and also sends the data to the restaurant's system.
The Safe Queue: But wait! It's Friday night and the restaurant is receiving 500 orders per minute! To protect the kitchen's database from exploding, SNS sends the orders to an Amazon SQS queue. The kitchen software pulls the orders from the SQS queue one by one, calmly, without crashing.

In this story, every microservice works independently. If the notification service breaks down, the kitchen is still receiving orders from the SQS queue!

💡 Bonus Tip: The "Backpressure" Trap

When I started exploring AWS, I thought: "I will just connect SNS directly to my database or my Lambda function to get messages fast!"

But this is a dangerous mistake, this causes a problem called Backpressure

Because SNS pushes messages immediately, if your system receives a huge peak of 10,000 events in one second, SNS will try to push all 10,000 events to your server at the same time. Your server will probably crash!

The solution architects use: The "SNS + SQS Fan-Out" pattern.
Never connect SNS directly to your final worker. Instead, put an SQS queue in front of every consumer. SNS will push the message to the queue, and your worker will pull from the queue safely. The queue acts as a shock absorber!

What messaging pattern do you use the most in your backend projects? Let me know in the comments! 👇

A Practical Guide to Azure PostgreSQL: Migration, Replicas, and Tuning ☁️🐘

Luis Núñez — Sat, 25 Jul 2026 02:12:00 +0000

In this post, I summarize my hands-on experience completing the Microsoft Applied Skills: Configure and migrate to Azure Database for PostgreSQL assessment.

Using Azure Portal, pgAdmin, and PostgreSQL, I walked through the core architectural tasks of setting up, securing, migrating, replicating, and optimizing a managed relational database in the cloud.

🛠️ Step-by-Step Lab Execution

1. Security & Monitoring Setup

Authentication: Configured dual authentication on Azure Database for PostgreSQL Flexible Server (psql63693133), enabling Microsoft Entra ID alongside native PostgreSQL authentication.
Network Isolation: Isolated server traffic within VNET1/subnet1 by creating a Private Endpoint (psql63693133-pe).
Diagnostics: Configured Diagnostic Settings (logs-to-loganalytics) to route PostgreSQL Sessions data logs to an Azure Log Analytics Workspace (loganalytics1).

2. Migration & Handling the B-Tree Index Error

Data Restore: Restored the adventureworks sample database to Azure using pgAdmin's restore tool.
Real-World Error: During pg_restore, a known error occurred due to the PostgreSQL B-tree index row size limit:

ERROR: index row size 2896 exceeds btree version 4 maximum 2704 for index "IX_ProductReview_ProductID_Name"

Resolution & Impact: This error was non-fatal. Because PostgreSQL restores table rows before creating secondary indexes, all schema structures and data were successfully imported. Only the secondary index on productreview.comments failed due to text size limits.

3. Cross-Region Read Replication

High Availability: Created a Read Replica (psql63693133-replica) to offload read-heavy workloads and increase resiliency.
Paired Region: Deployed the replica in Canada Central (the paired region for the primary server located in Canada East).

4. Query Performance Optimization

EXPLAIN Plan: Analyzed the public.address1() function in pgAdmin, extracted its underlying SQL query, generated the EXPLAIN execution plan, and exported the visual output.
Index Creation: Identified a sequential scan bottleneck on person.address and resolved it by creating a targeted index:

CREATE INDEX IX_Address_StateProvinceID 
ON person.address (stateprovinceid);

💡 Key Takeaways

Private Endpoints First: Always restrict database traffic to private virtual networks before migrating production data.
Understand Migration Logs: Non-critical index failures (like B-tree row limits on text columns) do not invalidate full data restores.
Analyze Before Scaling: Using EXPLAIN to spot missing indexes solves query bottlenecks without needing to increase expensive server compute tiers.

🚀 Try It Yourself

Put your hands-on cloud skills to the test with the official assessment module on Microsoft Learn:

👉 Microsoft Applied Skills: Configure and migrate to Azure Database for PostgreSQL