I'm new to AWS serverless applications and am looking for something like ocelot request aggregation on the AWS serverless stack.

Assume I have two AWS lambdas that return data needed by a SPA: A and B. They each take 1 second to run to load data from different sources. When the browser makes a call to the API I wish to run both concurrently and return the resulting JSON to the browser.

Two options I'm considering:

  1. A parallel state in a step function that runs A and B
  2. Have another lambda whose sole purpose is to run A and B concurrently and return the results

Testing both these I've found the step function takes an extra 220ms per call and the concurrent lambda takes an extra 500ms each call. These are both too slow for a SPA api. Is there a faster solution?

  • 1
    Browsers already have the capability to run such requests concurrently, if you do it the right way. See learning.oreilly.com/library/view/http-the-definitive/… Feb 19, 2020 at 15:11
  • 1
    what's the SPA framework?
    – Martin K
    Feb 19, 2020 at 15:59
  • @MartikK No real app exists yet but I was thinking Angular.
    – C.M.
    Feb 19, 2020 at 19:03
  • These are both too slow for a SPA api I disagree. Your current calls are already above 1 sec, so I find it difficult to believe that adding 220-500ms on top of that is an issue. An appropriately-built SPA would handle this gracefully with a loading indicator.
    – Dan Wilson
    Mar 13 at 21:36
  • Why would you give away $ (220-500ms) to Bezos?
    – Laiv
    Mar 14 at 7:23

2 Answers 2


There are two potential solutions that come to mind.

  1. Make concurrent calls from the browser and aggregate the results there (credit to @RobertHarvey who has already mentioned this in the comments)
  2. Make concurrent calls from the Lambda and aggregate the results before sending a response

Using JavaScript's Promise.all for example would work for both options.

Both of these options limit the number of components and hops your request(s) makes, meaning you should see quicker responses.

Option 1 should be faster overall (assuming each request isn't fighting over the client's bandwidth), but will be more expensive as you are invoking two Lambdas and potentially two API Gateway call if you are set up that way. It also lets you expose each API individually in the future.

Option 2 may be ever so slightly slower than option 1, but it's only one call from the browser, so only one API Gateway call and Lambda invocation. If your Lambdas are grunt heavy (which I doubt if they are just calling to external sources) you could increase the memory allocation of your single lambda and still be saving money.

I should point out that option 2 will only be slower than option 1 if there is a significant amount of code or heavy dependencies that couldn't be shared, and even then it would probably only be noticeable in cold starts.


Option 3 - Merge the lambda functions

Instead of having two separate lambda functions, simply move the logic of B into A and fetch the data in parallel.

You haven't indicated that this is not possible, so in my opinion it's a valid approach. You avoid the overhead of an aggregator step/lambda function, and only have to make one call from the browser.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.