Reliable Inventory Import — FDE Backend Challenge

Welcome. A customer has handed the Forward Deployed Engineering team a tiny inventory-import service. It works for a demo, but production deliveries are slow, duplicated, out of order, and occasionally rejected by the customer's catalog API.

The starter is intentionally small. Keep your solution small too. We care more about the guarantees you provide and how you verify them than about framework choice or UI polish.

Your task

Start from starter/ or replace it with a service in a language you know. Implement the HTTP contract in SPEC.md and solve the following customer problems.

1. Imports are too slow

The inherited implementation sends records one at a time. The catalog API is I/O-bound and takes roughly 120 ms per call.

Process independent records concurrently, but protect the upstream service:

• Use bounded concurrency, with no more than four catalog requests in flight.
• Retry 429 and 503 responses.
• Respect Retry-After when it is present.
• Do not retry permanent 4xx responses.

2. Deliveries are messy

Real deliveries contain malformed records, duplicate event IDs, and older updates that arrive after newer ones.

Your service must:

• Reject malformed records without losing the rest of the delivery.
• Send each valid event with its event ID as an idempotency key.
• Report duplicate and stale events separately from applied events.
• Produce the same final catalog state when a delivery is replayed.
• Never allow an older event to overwrite newer inventory.

The catalog API is the authority for the atomic idempotency and ordering check. Your importer is responsible for sending enough information for it to enforce those guarantees and for reporting its result accurately.

3. Make it operable

• Return a useful per-delivery summary, including retry and error counts.
• Emit structured logs containing the delivery ID.
• Return useful 400 responses for malformed requests.
• Add tests for the behavior you rely on.
• Package the service for Vercel using either a native runtime or Dockerfile.vercel.

Run the starter

The starter uses only the Python standard library:

cd starter
PARTNER_API_URL=http://localhost:9090 PORT=8080 python3 server.py

The shared evaluator starts its own deterministic catalog API, so the easiest way to exercise the starter is through the test suite:

cd solutions/test-suite
pnpm test:starter

The starter is expected to fail several tests.

Submission

Submit a repository containing:

1. Your implementation and dependency lockfile.
2. A Dockerfile.vercel, or native Vercel Function configuration.
3. Tests and instructions for running them.
4. A short DECISIONS.md. This is the place show how you design and approach software, and we strongly recommend you use your own words to describe it.
   • concurrency and retry policy;
   • idempotency and ordering guarantees;
   • limitations you would address before a production rollout;
   • how you used AI to create, validate, and ship the solution

Deploy the result to Vercel and include the public URL. Preserve commit history.

Optional durable extension

If you finish early, change POST /imports into a fast asynchronous submission flow backed by Vercel Workflows. Return a run ID, add a status endpoint, and show that processing resumes after a transient failure or deployment.

AI coding tools are allowed. You remain responsible for every line and should be prepared to explain, modify, and debug the service during the interview.