Y

Project · Advanced · about 30 hours

Design and build catalogue search for millions of products

Write a system design for product search over the full Open Food Facts catalogue, implement the critical path, and load test it against the targets in your design.

Skills:Go, NoSQL databases, Monitoring and observability, System design

Part of: Software Engineer (Backend)

Data and licences

Brief

A nutrition app wants search-as-you-type over the whole Open Food Facts catalogue, which holds millions of products, with p95 latency under 150 ms at a peak you estimate from the app's expected users. Treat this like a real design review: the document comes first, then you build the part that matters most and prove it works.

What to build

  1. Requirements and estimates: users, searches per user per day, peak queries per second, index size. Show the calculations.

  2. Choose a search approach (PostgreSQL full-text, OpenSearch, Meilisearch or similar) and justify it against the estimates.

  3. Implement GET /search?q=&filters= and GET /products/{barcode} in Go, with a cache for popular queries and stateless servers behind a load balancer.

  4. Load test at your estimated peak and at twice the peak. Report p50, p95 and p99 and where the time goes.

  5. Describe how you would handle ten times the data and traffic: sharding, replicas, precomputed suggestions.

Deliverables

  • Repository with docs/design.md, service/, load/ and REPORT.md

How it is graded

Reviewers check your estimates, rerun your load test, and challenge two design decisions. A design that misses its target but explains why honestly scores better than one that hides it.

Stretch

Keep the index fresh from the daily Open Food Facts delta export without downtime.

Deliverables

  • A design document with requirements, estimates, API, data model, high-level design and trade-offs
  • An implementation of the search and lookup path with an index, a cache and horizontal scaling of stateless servers
  • A load test that checks the latency and throughput targets from the design
  • A section on what changes at ten times the traffic and data

How a reviewer grades it

CriterionWeightWhat good looks like
Estimates are calculated and drive the design choices25%
Implementation meets the stated targets, shown by the load test30%
Trade-offs (consistency, freshness, cost) are explained honestly25%
Scaling plan is concrete and realistic20%