Insights27 February 2026Updated 26 October 20264 min read

Serverless Architecture for Spiky Smart Logging Workloads

A glowing digital tree with circuitry and data nodes under lightning, symbolising Data Logic and Dendro Logic concepts.

Serverless scaling needs limits as well as capacity. AWS explicitly provides concurrency controls to protect downstream systems. For a smart logging system, we would make the acceptance test about complete records and recovery time, rather than the number of functions started.

Consider a hypothetical field team reconnecting after a shift without coverage. Its inspection records arrive together, with photographs and follow-up work attached. We want the system to accept that burst without claiming that every record has already been checked, stored and made available to a supervisor. Those are separate milestones in the design we recommend.

Measure the burst before choosing the workers

A daily average is a poor basis for a burst test. In chapter 9 of Understanding Software Dynamics, Richard L. Sites shows how different arrival patterns can produce the same average rate. His practical advice is to examine shorter measurement intervals when looking for damaging bursts.

For our hypothetical logging service, we would capture arrival times and payload sizes, then replay the busiest interval against the proposed pipeline. Include a quiet period followed by a sudden upload, rather than testing only a steady stream. Record how long it takes the final accepted record to become usable. Agree that deadline with the people who need the information before selecting a concurrency setting.

We would also separate small structured entries from attachment processing in the test results. The question is whether the whole record meets its deadline, including its evidence, rather than whether the easiest part finished quickly.

Put a queue between receipt and processing

A dense burst of light particles enters an orderly queue that feeds a row of workers at a steady pace

AWS documents a concrete pattern in which Lambda polls SQS and passes messages to a handler in batches. Its November 2023 announcement described polling scale-up that could add up to 300 concurrent executions per minute. That is a documented scaling rate for this integration, not a promise of instantaneous processing for an arbitrary application.

We would use that separation to give receipt a precise meaning. Return an accepted status only after the intake operation has met its defined persistence requirement. Keep a separate processing status for validation, attachment handling and the final business write. A supervisor should be able to distinguish an accepted upload from a completed inspection record.

Test the transition between each status. Stop a worker after receipt and confirm what the user sees while the record is still waiting. Treat a successful intake response as evidence for intake alone, never as proof that every later operation succeeded.

Bound concurrency at the dependency

Many workers of light converge on a narrow gate before a database cylinder, only a few allowed through at once

AWS places maximum concurrency on the SQS event source mapping, separately from a function's reserved concurrency. The same article explains that a dead-letter queue needs a separate mechanism to inspect and process its messages. Moving failed work there is therefore not a completed recovery process.

Our design recommendation is to establish the sustainable processing rate of the database and any external service before raising worker concurrency. If a record triggers a notification or another business action, include that dependency in the test. Set an explicit limit, then repeat the burst and failure tests at that limit.

Give failed records an owner and an inspection procedure. We would require that procedure to explain how a repaired record is replayed and how its final outcome is reconciled with the original upload. Do not make the absence of active worker errors the acceptance criterion for an empty backlog.

Make retries safe at record level

AWS's partial batch response support lets Lambda report an SQS batch as partly successful so that only failed records need reprocessing. This provides a mechanism for avoiding a whole-batch retry when some records have succeeded.

We would test a batch containing a deliberately invalid inspection alongside valid entries. Require the handler to identify the failed record correctly, then check that the valid records remain complete. A second test should interrupt processing after a business write but before the worker reports success. The expected outcome should be written down before running either test.

The complementary design rule is idempotency. AWS's guidance describes reusing a token across repeated requests so they do not create duplicate records or side effects. For the hypothetical inspection, we would keep its identity stable across retries and verify that a repeated submission does not create a second business action. Agree what should happen if that identity is reused with changed content, rather than silently treating a correction as a duplicate.

Prove recovery separately from scaling

AWS's failure-management guidance calls for backups of data, applications and configuration against recovery objectives, alongside regular recovery testing. Increasing the worker count does not perform that backup and restore exercise.

We would define how much accepted information the business can afford to lose and how long recovery may take. Then restore a representative dataset into an isolated environment and check that records can be read with their attachments and processing history. Include configuration in the exercise, so the test covers the service needed to use those records.

For the logging service, our release condition would be a reconciled result: accepted records accounted for as completed, still pending or explicitly failed, with recovery demonstrated within the agreed deadline. We would choose serverless where that tested design fits the workload. We would not choose it on the assumption that automatic scaling proves continuity or guarantees lower costs.

Update, October 2026

For teams using agents to implement this pipeline, we recommend our engineering article on independent review and live verification before merge. Apply that discipline to the burst and recovery acceptance tests above.

Sources

Want this in your team?

Tell us what you're building and where you want to get to, and we'll think it through with you.

Let's have a chat Follow by RSS →

All insights →