SELECTED WORK / 04 / JAVA 21
E-Commerce Search Backend.
Comparable search paths with operational controls
Four search paths. One comparable system.
Spring Boot commerce backend with four comparable search paths, asynchronous benchmark jobs, and operational health controls.
01 / THE PROBLEM
What made this hard
A commerce service needs to compare retrieval behavior across simple SQL matching, database full-text search, memory, and an external search index without confusing distinct workloads.
02 / ROLE & CONSTRAINTS
What I owned
Built a self-directed Java 21/Spring Boot backend with commerce endpoints, search paths, indexing jobs, and contract checks.
Each search path needs its own data/index freshness boundary, while catalog, checkout, and authorization remain coherent across the backend.
03 / DECISIONS
How the boundary works
- 01
Expose SQL LIKE, PostgreSQL full-text, in-memory, and OpenSearch retrieval paths for comparison.
- 02
Use Kafka-driven indexing and asynchronous benchmark jobs to collect latency, relevance, throughput, and freshness observations.
- 03
Cover endpoint contracts, authorization expectations, and a buyer-flow smoke path in Java CI.
04 / FAILURE CASE
The case worth testing
An index can be stale while database-backed results are current; the comparison must account for freshness rather than presenting latency alone as a winner.
05 / PROOF & LIMITS
What the evidence supports
The public repository contains Java CI, API contract tests, and a buyer-flow smoke test. No new benchmark numbers were measured for this case study.
Self-directed backend project. No customer deployment, performance advantage, or production search volume is claimed.
TOOLS & TECHNOLOGIES