Jonathan Franklin
Problem
Pricesearcher’s website, browser extension and external integrations needed product data from both the company’s Elasticsearch index and third-party providers. Combining those sources meant dealing with different response formats, provider latency and client ranking requirements. The API also needed clearer boundaries between the interfaces used by different clients.
Architecture
The Python/Flask API combined the internal Elasticsearch index with Amazon, Yahoo and Kelkoo. Third-party requests ran asynchronously and provider failures were handled separately. Redis with RediSearch supported filtering, sorting and facets over cached results. Web, browser-extension, external-client and core APIs ran as separate deployments with their own OpenAPI specifications.
What I built
- Added the multi-source products endpoint and provider integrations.
- Added streaming responses for larger result sets and a result-handler layer for client-specific relevance ordering.
- Worked on splitting the monolith into client-specific deployments and specifications, including shared legacy routes.
- Maintained the price-lookup APIs, query-expansion service, Docker images, Terraform and Jenkins deployment tooling.
Engineering decisions
- Third-party integrations ran asynchronously, with separate handling for provider failures.
- Cached results could be filtered, sorted and faceted in Redis without querying Elasticsearch again.
- Separate deployments and OpenAPI specifications made each client-facing boundary explicit while retaining shared legacy routes.
Technologies
Python 3.7, Flask, Elasticsearch, Redis with RediSearch, MySQL, boto3/AWS, Docker, Terraform, Jenkins, OpenAPI.
Results
The API could combine internal and third-party product results while supporting different ranking requirements for its clients. Separate deployments and specifications made the client-facing interfaces more explicit, alongside the existing price-lookup and query-expansion services.