PlayCloudLabs
Sign in
  1. Learn AWS
  2. Architecture
  3. Queue-based load levelling

Architecture pattern

AWS Queue-based load levelling architecture

when the front takes more than the back can absorb

The classic answer to a spike hitting a system that cannot spike with it. Intake accepts and enqueues in milliseconds, so the customer gets an answer immediately; the worker drains at whatever rate the database can actually take. The queue is also the thing that stops an outage losing work.

What it runs through

In the order a request or a record moves through it. Each one links to the page that explains it.

Signals in a brief that point here

Phrases that, when you meet them in a scenario, mean this shape rather than another. They are the tell, and they are what an exam question is built around.

  • “traffic spike”
  • “must never reject an order”
  • “downstream can only handle so much”
  • “must survive an outage”
  • “processed in order”

What it costs you

The answer to the customer becomes "accepted", not "done". Anything that must be confirmed synchronously cannot go behind the queue.

Every shape has one. A design decision with no stated downside is usually a decision nobody has finished making.

Learn the services in it

Shapes it is easily confused with

These run through some of the same services, which is exactly why a brief that fits one can look like it fits another.

Now build it from a brief

Reading a shape and producing one from a scenario that never names a service are different skills, and the exam asks for the second. The scenarios give you the brief; you draw the architecture and it is scored against what the brief requires.

Still there?

You have been away for a while. We have saved what you were working on in this browser. In 60 seconds you will be signed out to keep your account safe.