CloudArcade

Guided architecture tour · 6–8 min

Keep a busy function from flooding a database — Lambda and Concurrency

Choose a limit that keeps function traffic within a database’s capacity.

This tour teaches architecture decisions. Its services are not provisioned in the emulator.

Your goal

Choose a limit that keeps function traffic within a database’s capacity.

Why this matters

A burst of orders starts many function runs at once. You will estimate safe overlap, limit it, and decide what should happen when requests must wait.

Words you will use

Concurrency means runs happening at the same time. Reserved concurrency sets aside capacity for a function and caps its simultaneous runs.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

Play this architecture tour

1. Count overlapping work

Each function run opens a database connection. A burst can start more runs than the database can comfortably serve. Choose the useful measurement.

What should guide the limit?

Safe database connections and function behavior.

Use measured downstream capacity and account for connections used by other apps. Concurrency is about overlapping runs, not just requests per day. The safe value depends on what each run does.

The limit is based on the system the function calls.

Downstream capacity → safe overlapping runs

2. Set the right kind of limit

You want a ceiling on simultaneous runs of this function. You also want capacity reserved for it within your account’s limits. Choose the setting.

Which setting fits?

Reserved concurrency.

Reserved concurrency provides a reservation and a maximum for that function. It does not pre-initialize execution environments; provisioned concurrency addresses that different need.

The function has a deliberate concurrency ceiling.

Reserved concurrency → capacity reservation + ceiling

3. Plan for excess work

Requests keep arriving after the function reaches its limit. Some invocations may be throttled, depending on how they arrive. Choose the next design step.

What must you plan?

Buffering or bounded retries appropriate to the event source.

A limit protects a dependency but does not make excess work disappear. Understand the source’s retry behavior, use a queue when suitable, and monitor throttles and backlog so waiting work stays visible.

The system has a plan for traffic beyond its limit.

Burst → queue or retry policy → controlled processing

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.

Continue with another AWS learning guide