Take-Home Assessment: Production Backend Challenge

Overview

This assessment is for a Mid-Senior Backend Engineer role focused on production systems.

• Primary stack: Node.js (TypeScript recommended)
• Databases: PostgreSQL or MySQL
• Expected effort: 5-7 hours

AI tools are allowed and encouraged. We are evaluating backend fundamentals, system thinking, and production readiness, not speed alone.

---

Scenario

Build a backend service for a multi-tenant FlashSale Inventory & Orders platform used by multiple stores.

Each tenant should be able to:

• Manage products and inventory
• Configure flash-sale campaigns
• Accept customer orders during campaign windows

The system must handle high-concurrency purchase attempts without overselling.

---

Functional Requirements

1) Multi-Tenant Product Management

Implement product management with tenant isolation.

Minimum product fields:

• id
• tenant_id
• sku
• name
• price
• stock

Requirements:

• Tenant isolation must be enforced server-side
• price must be stored safely for monetary operations (avoid floating-point errors)

2) Flash Sale Campaigns

Implement campaign creation and activation logic.

Minimum campaign fields:

• id
• tenant_id
• product_id
• start_time
• end_time
• max_per_user (optional)

Requirements:

• Campaign windows must be time-bound and validated
• Time values must be stored in UTC and returned in ISO 8601 format with timezone
• Boundary behavior must be explicitly documented and implemented consistently (start_time/end_time inclusivity rules)

3) Order Placement

Implement order placement for active campaigns.

Order requirements:

• No overselling (stock must never go below zero)
• Respect max_per_user when configured
• Support idempotent retries from clients using an idempotency key
• Ensure there is exactly one source of truth for stock deduction

4) Order Statuses

Support these statuses:

• PENDING
• CONFIRMED
• REJECTED

Requirements:

• Rejected orders must include a machine-readable reason code
• Error responses must include: code, message, request_id

5) Querying and Pagination

Provide order listing per tenant with:

• Pagination
• Filtering by status
• Filtering by date range

Requirements:

• Pagination must be deterministic and stable across pages
• Sorting behavior must be documented

---

Non-Functional Requirements

Concurrency and Correctness

• Design for concurrent requests on the same product/campaign
• Demonstrate how race conditions are prevented

Reliability

• Handle transient DB/network failures gracefully
• Document retry behavior and where retries are safe
• Define an idempotency key retention/TTL strategy

Observability

• Structured logging
• Health endpoint
• At least 2 meaningful metrics (examples: request rate, rejection reason counts, p95 latency)
• Support request correlation ID from header; generate one if missing

Performance and Scale

• Solution should support at least 200 req/s burst locally, or include a reasoned design and bottleneck analysis
• Explain horizontal scaling strategy and likely bottlenecks

Security Basics

• Input validation on all write endpoints
• Tenant access checks must not rely on client-provided trust alone

---

Technical Expectations

• Containerized local setup (Docker / docker-compose)
• DB schema + migrations included
• API documented (OpenAPI spec or Postman collection)
• Tests:
  • Unit tests for critical business rules
  • Integration tests for high-risk flows (especially order placement and idempotency)

---

AI Usage Policy

You may use AI tools.

Include:

1. AI_USAGE.md

   • Which tools you used
   • High-level prompt categories
   • What you accepted/changed/rejected and why

2. Ownership statement in your submission:

   • "I can explain and defend every architectural and implementation decision in this solution."

---

Deliverables

Submit a repository containing:

• Source code
• README.md with setup/run instructions
• ARCHITECTURE.md covering:
  • Data model and indexing choices
  • Concurrency strategy
  • Scaling strategy
  • Failure modes and mitigations
• AI_USAGE.md
• Tests and test run instructions
• API specification/collection

---

Submission Notes

• Keep assumptions explicit and documented.
• Prioritize production-ready decisions over excessive framework complexity.
• We value clear thinking and consistent behavior under load more than feature volume.