Rhussel
Combo.

The apply operation locks the user’s budget updates, checks a saved request hash for retries, and revalidates the preview’s financial context before writing.

if (snapshot.getAppliedPlanId() != null) {
    if (!requestHash.equals(snapshot.getAppliedRequestHash()))
        throw conflict("This recommendation was already applied with different amounts");
    return applied(snapshot, recommendation, true);
}

// Later, after loading the current financial context:
if (!json.hash(context).equals(snapshot.getInputHash()))
    throw conflict("Financial inputs or the target plan changed; generate a new preview");

Selected excerpt from BudgetPlannerService.apply; surrounding validation omitted for readability.

Integration-test coverage

• Concurrent identical applies return the same plan.
• Changed spending history or target plans produce a conflict.
• Overwrites require confirmation and edited allocations respect constraints.
• Another user cannot access or apply the recommendation.

Cases present in BudgetPlannerApiIntegrationTest.java. This describes test coverage, not a live test run.

A saved run on 12 May 2026 used a custom Node.js load script against a Render service with Aiven MySQL. This is a separate environment from the AWS deployment described above.

Zero request errors did not mean the latency targets passed: the administrator baseline and normal-load scenario exceeded the report’s thresholds. These measurements describe that test environment and run, not current performance.

Source: load_test_report_2026-05-11T17-23-21.md. Separate k6 scripts are also part of the project; the figures above come from the custom Node.js run.