Optimise network performance across endpoints

[wilkinsocks]

Description

We’ve seen quite a high time-to-first-byte (TTFB) on GET /letters.

I took a quick look to see if there are any low-risk quick wins that could reduce response time without changing any behaviour.

This is motivated by the "AT15 – Performance testing" acceptance testing requirement.

1. Lambda memory allocation

The get-letters Lambda appears to be configured with a low memory setting.

Increasing memory size in Lambda functions also increases available CPU and network bandwidth, which can reduce latency (and often cost) for functions with network I/O.

AWS only recommends 128 MB for very simple functions, based on the work going on in this function I think it'd benefit from an increased setting. I've set all functions to 512 MB as a baseline, and get-letters to 1024 MB.

Ref: https://docs.aws.amazon.com/lambda/latest/dg/configuration-memory.html#configuration-memory-use-cases

2. Pretty-printed JSON responses

It looks like the handler returns formatted JSON (indentation/newlines).
Bearing in mind get-letters returns a large payload, this would add:

• Extra CPU in the Lambda to format the string,
• Larger payload over the network,
• More parse work client-side

Returning compact JSON would be functionally identical, just smaller/faster and reduced network bandwidth. On one test it was around ~40% reduction in payload size.

The indention formatting has been removed from responses.

3. Max results per call

In the testing Q&A: "The API has been restricted to have 1500 letters being returned per call…" I wondered whether max_get_limit should be aligned with that (to avoid the API returning more than intended).

Context

This PR attempts to optimise network performance across lambda functions without changing code or behaviour, giving consumers additional time budget in performance testing.

Type of changes

• Refactoring (non-breaking change)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would change existing functionality)
• Bug fix (non-breaking change which fixes an issue)

Checklist

• I am familiar with the contributing guidelines
• I have followed the code style of the project
• I have added tests to cover my changes
• I have updated the documentation accordingly
• This PR is a result of pair or mob programming
• If I have used the 'skip-trivy-package' label I have done so responsibly and in the knowledge that this is being fixed as part of a separate ticket/PR.

---

Sensitive Information Declaration

To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.

• I confirm that neither PII/PID nor sensitive data are included in this PR and the codebase changes.