Learn what Lambda, SQS, DLQ, S3, and DynamoDB each do
and directly see how messages are redelivered and isolated in the DLQ.
Bulk dispatches, external API integrations, and increasingly lengthy batches. The moment you are assigned this work, you face problems that cannot be solved by simply writing better code. That is because the architecture determines how long each request holds resources and what needs to be resent when the process is halfway through.
AI now boosts implementation speed. The remaining bottleneck has shifted to deciding which architecture to choose and where the message will end up if something fails. And you cannot make that decision without seeing queues and DLQs actually run at least once.
This course captures that one-time experience in six lessons totaling 75 minutes.
Three things set it apart.
With Docker and LocalStack, run SQS, Lambda, S3, and DynamoDB locally. Without registering a payment method or configuring IAM permissions, you can start hands-on practice right from Lesson 1. There is no point at which accidental charges can occur.
Instead of memorizing the feature lists of the five services, you will follow one message step by step as it is published, consumed, failed, redelivered, and eventually isolated in the DLQ. First, draw a map of the roles, then move the message across it.
The tricky part is when only half of it has been sent. You will directly verify how many times it is redelivered, when it moves to the DLQ, and what you can do afterward.
· Spring Boot basics — Intended for those who have built a REST API themselves at least once.
· AWS service tour — We cover only the five listed above.
· Production operations and cost optimization — Outside the scope of this course
We’ll first look at why the architecture breaks down when only the number of recipients increases.
In this structure, the controller calls the external API in a loop through the service layer. As the number of recipients increases, the time a single request remains active increases accordingly. If the vendor slows down, the response does not return, and a single request holds onto resources for that amount of time.
More troublesome is what comes next. When the message is about halfway sent, it is difficult to know what succeeded, and running it again sends it to people who have already received it.
In a structure where retries immediately result in duplicate sends, “running it one more time” is not a solution.
The API only accepts the request and responds immediately. The queue holds incoming requests and feeds them through at the processing side’s pace. Failures are recorded per item.
In Lesson 1, you will compare the two architectures using these four dimensions(response timing · failure unit · retry owner · scaling unit) and fill out comparison notes based on your own project.
The question is how far to divide the responsibilities.
If you put querying, splitting, sending, and recording all into a single Lambda, you can hit the execution time limit, and when a partial failure occurs, you won’t know where to restart. That’s because retries rerun the entire process.
In Lesson 2, we divide up the responsibilities of the five services and create all five components ourselves through hands-on practice. We create the queue, DLQ, bucket, and table, then verify them in a list.
Upload the payload and recipient files to the repository, and include only a single key string in the message. In the hands-on exercise, upload them yourself and visually confirm what goes into the message.
We won’t stop at explaining the concept; we’ll verify it on the screen before moving on.
Even after receiving and processing it, if you do not delete it, it will return with the same MessageId after the visibility timeout expires. If you delete it after receiving it, it will be empty when you check again.
In the hands-on exercise, we will create these two cases in sequence. Here, we confirm that receiving, processing, and deleting constitute one set.
At-least-once delivery is the default. Duplicates are not an exception but an assumption, and the responsibility for converging the result to one outcome remains on the processing side.
If a message cannot be processed and fails the prescribed number of times, it disappears from the main queue and remains in the DLQ. In the exercise, you will exceed the limit yourself and query both queues separately to verify this.
At the end, delete the queues, buckets, and tables you created, and stop the containers. The goal is to become familiar with the cleanup sequence at the end of the exercises.
Deployment is not a means of verification.
The hands-on exercise in this pre-course is in Step 3. It runs in a single Docker container and incurs no cost.
At the same time, you will also verify through hands-on practice what local development does not catch. Even if you change the credentials to an incorrect value, the local environment still passes as before. That is why we do not skip the five steps.
Even bulk requests are handled with loops and synchronous calls, and when things slow down, the first thing that comes to mind is the server’s specifications.
I explain why intake and processing should be separated in terms of response timing, failure units, and the entity responsible for retries.
It’s difficult to put the difference between SQS and DLQ into words.
I explain with a screen I built myself that the queue handles waiting and buffering, while the DLQ handles isolating repeated failures.
We treat situations where the same message arrives again as nothing more than exceptions.
Distinguish between the fact that duplicates are expected and the fact that responsibility for converging the result to a single outcome remains on the processing side.
The resources created during the exercises have accumulated in the account.
By the end of the hands-on exercise, you'll be familiar with the order for deleting things.
Click to expand what you do in each lesson.
Launch one container and verify the connection. We also point out the trap where the container exits immediately if you omit the tag.
Compare request processing and event processing side by side. The deliverable is a comparison memo.
We divide up what each of the five services is responsible for and what it is not responsible for.
We’ll summarize the six steps and the pass criteria for each, then verify through hands-on practice what the local environment does not handle for us.
It is the longest river and the core exercise.
We identify the questions the pre-course doesn’t answer and how to answer them through verification.
Answer yes or no and count your score. If you get 6–7, you’re ready for the next step; 5 means retaking that course; 4 or fewer means reviewing the pre-course once more.
This assessment covers only the basics of AWS serverless. If you have no experience implementing Spring Boot APIs, you are not yet ready for the next step regardless of your score.
I design and operate systems that send more than 10 billion messages annually and process hundreds of thousands of user behavior events per second. I am a second-year backend developer who has experienced everything from early-stage development to large-scale traffic handling at three startups.
The queues, redelivery, and DLQs covered in this course are things I encounter every day in the field. Most of what I learned came not when things were running smoothly, but when they fell apart.
However, we do not use company code or internal materials. We recreate the same situations using publicly shareable examples and synthetic data. We send the same message through multiple times to verify that idempotency is maintained, and change the vendor responses to 429 and timeout to see how throughput is regulated. We also run the entire process on screen, from failed messages being moved to the DLQ to being processed again.
Lecture · Technical validation · Student support: Kan (Lee Chang-min)
Curriculum · Textbook · Editing: Park Hyun-jun
Co-produced by: Dingco Labs
How can you tell whether it truly won’t break, how do you converge duplicates into a single instance,
and what must you do to prevent one customer’s surge from starving others?
LocalStack 4.9. The latest and stable tags require a license token, causing the container to exit immediately.Docker and AWS CLI. You do not need an AWS account or incur any costs.
