Own the behavior behind a booking and payment journey

An airline backend revamp supported booking, booking management, check-in and related customer journeys. Within an eight-developer backend team, I primarily owned the Order and Notification services and handled the main design, coding, tests and integration for separate booking-management and booking-query services.

The engineering challenge was to make the order journey behave correctly across concurrent requests, separately owned payment services and external booking and messaging providers.

I worked with Java 21, Spring Boot 3, WebFlux/WebClient, PostgreSQL/R2DBC and Redis. I designed API contracts and the order data model, mapped provider responses and errors, and implemented booking creation, retrieval and update behavior.

The booking-management and query services were independently deployable services, rather than modules inside Order Service. I owned their main implementation and integration work. Major or cross-system decisions were reviewed with the Backend Lead or client technical lead according to scope.

I designed and implemented layered protection for concurrent order/payment requests, choosing mechanisms according to the flow or stage. Database row locks serialized local order changes; optimistic versions detected stale updates; Redis locks coordinated service instances and rapid user resubmission; state guards blocked repeated or invalid transitions.

I also handled stale-lock and timeout recovery and the idempotency checks needed when requests were retried. Local database transactions covered local changes. Remote payment or booking calls required state handling and recovery rather than assuming a transaction could roll back every service.

Payment Service belonged to another team. My responsibility was the Order-side contract, request/response mapping, payment-related state changes, error handling and tests.

I integrated booking behavior with the reservation provider through REST/JSON calls and primarily reactive Mono/Flux flows. This included provider mapping, timeout handling, conditional retries and unit/integration tests.

Unlike the later mobile BFF’s display-only price work, this project included monetary conversion using provider-supplied exchange rates, plus loyalty amount conversion, eligibility and balance/rule checks. I implemented calculations, rounding, validation and error mapping against business rules confirmed by the client/Product Owner.

For notifications, I integrated email and SMS providers for booking/order confirmations, payment outcomes and booking-status changes. I owned template/payload mapping and application-level retry and failure paths. The dispatch was fire-and-forget, with no message broker; it was not a guaranteed-delivery system.

I wrote unit and integration tests, including concurrent-request cases and provider-failure paths. Tests used JUnit 5, Mockito and a PostgreSQL test environment, with external providers mocked or stubbed where appropriate.

I handled staging readiness and deployment and supported go-live troubleshooting through application logs in the AWS environment. The Backend Lead owned the GitHub Actions workflows, and the client release team performed production deployment.

The system reached production in Q4 2024. My service ownership covered implementation and delivery support within the wider programme; it was not a people-management role.