N3XTCODER Fullstack Developer Challenge

Please submit your solution as a pull request (PR) to this repository. If you cannot open a real PR, send a .zip containing a Git repository.

Include a file called SOLUTION.md in the repository root. In it, explain your reasoning, trade-offs, and assumed constraints for all three challenges.

Your solution will be reviewed in a follow-up video call, so be prepared to discuss your design decisions in depth.

---

1. Deduplicator for unbounded streams

You receive words from an external source. The source is represented as an async function* readWords(): AsyncGenerator<string>. You do not know when it ends, but it can be very long. You cannot store all previously seen words in memory.

Implement two functions in the language of your choice:

// Approximate deduplication: only guarantees uniqueness for the last N items seen.
// Should have bounded memory usage regardless of stream length.
function deduplicateApproximate(source: AsyncGenerator<string>, windowSize: number): AsyncGenerator<string>

// Exact deduplication: guarantees global uniqueness.
// May use disk / external storage if needed. Must not store all seen words in RAM.
function deduplicateExact(source: AsyncGenerator<string>): AsyncGenerator<string>

What we want to see:

1. Working, readable code for both functions.
2. A discussion in SOLUTION.md:
   • Why is the approximate version acceptable under certain conditions?
   • What are the trade-offs of your exact solution?
   • What happens to performance when the stream is 1 TB long?
3. Unit tests that demonstrate correctness for both, including edge cases (the same word repeated many times, empty source, words > window size, etc.).

---

2. Booking system data schema and bug remediation

A junior developer designed a schema for a peer-to-peer car-share booking system. Here is their design:

CREATE TABLE car (
  id UUID PRIMARY KEY,
  owner_id UUID NOT NULL,
  model VARCHAR(255),
  location VARCHAR(255)
);

CREATE TABLE booking (
  id UUID PRIMARY KEY,
  car_id UUID NOT NULL REFERENCES car(id),
  borrower_id UUID NOT NULL,
  start_time TIMESTAMP NOT NULL,
  end_time TIMESTAMP NOT NULL,
  status VARCHAR(50) DEFAULT 'confirmed'
);

The junior also added this requirement: support can update booking.end_time to extend a reservation when a borrower calls in.

The schema works for basic cases, but a borrower just reported a critical bug: they reserved a car from 10:00 to 12:00, then called support to extend to 14:00. The system allowed the extension, but another borrower had already booked 13:00 to 15:00 for the same car. The database now contains two overlapping bookings for the same vehicle.

Using a relational or document schema of your choice:

1. Identify the flaw in the schema logic (explain in SOLUTION.md).
2. Propose a corrected schema that prevents overlapping reservations for the same car. You must enforce this at the database level (or explain why you cannot).
3. Write the query you would use to list all cars available for a given time window (e.g. "available between 2024-10-01 09:00 and 2024-10-01 17:00"), even if some bookings exist.
4. Provide a migration script or equivalent transformation from the flawed schema to the corrected one.

What we want to see:

1. Schema definition (SQL, Prisma, Mongoose, JSON—whatever fits).
2. Query example.
3. Why your fix is better than alternative approaches (e.g. application-level checks only).
4. How your schema handles cancellation or partial extensions.

---

3. FrontOps with immutable artifacts

You are preparing a React application for production. The application calls an API whose base URL is different in staging and production. The ops team enforces a strict rule: the same compiled Docker image must be deployed to both environments. They also refuse to mount files or environment variables into running containers from outside orchestration (no mounted .env files, no runtime docker run -e).

Your task:

1. Provide a Dockerfile that builds the app once and produces a single image.
2. Describe the mechanism by which the app discovers API_BASE_URL at runtime in both environments, despite the same artifact.
3. List the exact steps the DevOps engineer must take to change the FQDN for staging vs. production. This must not require rebuilding the image.
4. Explain how a new version of the API (e.g. v2) would be introduced without redeploying the frontend container. What changes in the frontend code or infrastructure?

What we want to see:

1. Dockerfile or equivalent build artifact.
2. Configuration strategy (e.g. runtime config injection, Nginx sub_filter, etc.).
3. Clear operational steps (e.g. "set this value in this specific store").
4. A brief note in SOLUTION.md on the trade-offs you accepted.

---

How to submit

1. Fork or create a private repo.
2. Complete all three challenges.
3. Ensure your commit history shows iterative development, not a single upload.
4. Open a PR (or send the repo) with your solution.

Success criteria: Code that compiles/runs, tests that pass, and an honest SOLUTION.md demonstrating that you thought about it.