[Backend-Interview] Create CRUD API project - Andrew Dodson

[asdodson]

Customer Financing API — Backend Implementation

See updated README.md for additional information for overall project design and architecture

This PR introduces a Spring Boot REST API for managing customers and their credit applications at a car dealership. The core of the work is two main resources — customers and credit applications — wired together with a straightforward layered architecture: controllers, services, repositories, and JPA entities.

A few things worth focusing on in review:

State machine logic in CreditApplicationService — applications flow through SUBMITTED → UNDER_REVIEW → APPROVED/DENIED. The transition validation is the most business-critical piece here and worth verifying the edge cases are covered (especially invalid/terminal transitions returning 409).

Custom validators — there are cross-field and field-level constraints (@ValidLoanAmount, @ValidSSN, @ValidAdultAge, etc.) that are a bit non-standard. Worth confirming the error response shape from GlobalExceptionHandler matches what the frontend would expect.

AWS integration — S3 presigned URLs for document uploads/downloads and SQS publishing are wired in but off by default. The no-op implementations stand in locally. The conditional bean wiring in the config classes is worth a look to make sure it degrades cleanly when aws.enabled=false. The delete paths (both customer and credit application) are worth a close look — S3 cleanup intentionally runs before the DB delete so that if S3 throws, the record survives for retry.

Query performance — Customer delete uses a JOIN FETCH query (findByCustomerIdWithDocuments) to load all applications and their documents in a single SQL join rather than lazy-loading per application. The paginated credit application endpoints use @batchsize(size = 25) on the documents collection, which collapses per-application lazy loads into batched IN (...) queries without touching pagination or return types.

MapStruct mappers — SSN is masked in responses (only last 4 digits exposed). The Spock specs for the mappers cover this but it's a sensitive enough area to double-check manually.

Testing — there's a mix of unit tests, @WebMvcTest/@DataJpaTest slice tests, and full @SpringBootTest integration tests. The integration tests use H2 with seed data that resets per class, so test isolation should be solid, but the ordering of operations in CreditApplicationServiceIntegrationTest is worth a scan. The SQL fixture for CreditApplicationRepositoryIntegrationTest includes supporting document rows to cover the fetch join behavior end-to-end, including a DISTINCT guard test (without it, a join across multiple documents would duplicate application rows).

Running tests and additional information for manual tests:
See documentation for how to run automated tests and manual tests in - /docs/curl-demo.md and /docs/testing.md

See example curl test scripts in /curl/credit_applications and /curl/customers