Case study / 
CommerceIQ
From an idea to a working system.
Building Media Planner from inception, connecting Java services and AWS workflows, and guiding the team along the way.
Software Development Engineer II · Media Planner
An end-to-end Media Planner product, with application services, automated workflows, and concurrency improvements.
Media Planner built from inception
A new Media Planner product built from inception.
Media Planner needed an architecture that could support automated media-planning workflows. The work combined application services, serverless orchestration, concurrency, and the practical task of bringing a new product into operation.
Led development of the microservices architecture using Java, Spring Boot, and multithreading.
Developed a serverless Step Functions pipeline using AWS Lambda, SQS, and S3.
Provided technical leadership and mentoring throughout the end-to-end build.
Resolved concurrency issues through batch-processing optimizations that reduced infrastructure costs.
The delivered scope and outcome are based on my professional experience. Internal benchmarks, production topology, rollout records, and alternative evaluations are not published here. The engineering considerations below describe how I reason about this class of system; they do not assert undisclosed implementation details.
Engineering considerations for this class of system. The delivered work is described in the contribution and implementation sections.
Retries are useful recovery mechanisms, but a retried task can repeat a side effect. An automated planning workflow needs explicit idempotency boundaries: identify the business operation, distinguish retryable failures from invalid input, and make repeated execution converge on the intended result. Orchestration alone does not prove those properties.
AWS Lambda: idempotent processing practices (opens in a new tab)Concurrency should fit downstream capacity. For SQS-backed Lambda processing, partial batch responses can prevent successful records from being retried along with failed ones. Evaluate queue age, processing latency, retry volume, and downstream saturation together; raising parallelism without those signals can move a bottleneck into another service.
AWS: handling SQS batch failures (opens in a new tab)Service boundaries, orchestration, and team ownership need to fit together. A useful architecture makes the next feature easier to build and the next operational problem easier to understand.
An end-to-end Media Planner implementation, with serverless workflows and improvements to concurrent processing.
Next case study / 
GlobalLogic
