backend-task-data
Shipped: Library loans
Built a FastAPI/SQLite library-loans API with four related tables and 11,000 seeded loan records. The README includes before/after query plans and benchmarks showing the endpoint runs under 200 ms. Database constraints prevent double lending, and automated tests verify all requirements. Repository: https://github.com/quratulain-nayeem/library-loans-api Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Library loans
Repository: https://sgm322.github.io/LibraryLoansAPi/ Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Ticket sales
Built a concurrency-safe Ticket Booking REST API using Node.js and MySQL (InnoDB) meeting all Brief B criteria: 1. Data Model & Integrity: Normalized schema with events, seats, and orders using foreign keys, CASCADE constraints, and a UNIQUE constraint on seat reservations. 2. High-Volume Inventory: Seeded 10,000+ seat records across 5 events via an automated stored procedure. 3. Sub-200ms Latency: Implemented composite index idx event reserved on (event id, is reserved); GET /events/:id/free-seats fetches 2,000 available seats in under 25 ms. 4. Concurrency & Race Condition Safe: Applied pessimistic row locking (SELECT ... FOR UPDATE) inside database transactions. Verified via parallel PowerShell background jobs showing one request succeeding (201 Created) while simultaneous conflicting attempts fail (409 Conflict). Full schema, setup commands, and execution proofs are documented in the repository README.md. Repository: https://github.com/roh155/ticket booking Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Ticket sales
What Was Built A ticket reservation API with three endpoints: 1. GET /events — lists all events 2. GET /events/:eventId/seats/free — lists free seats for an event (27,040 seats for event 1) 3. POST /seats/:seatId/reserve — reserves a seat with race-condition protection Acceptance Criteria — How to Verify 1. Three or more related tables with foreign keys node -e "const db = require('./db'); console.log(db.prepare(\"SELECT sql FROM sqlite master WHERE type='table'\").all().map(r = r.sql).join('\n\n'))" Shows events, seats (FK to events), and orders (FK to seats) with constraints. 2. At least 10,000 seeded rows npm run seed node -e "const db = require('./db'); console.log('Seats:', db.prepare('SELECT COUNT( ) as c FROM seats').get().c)" Outputs Seats: 135200. 3. Listing free seats responds in under 200ms npm start node race-test.js or time the endpoint Response time: 20ms for 27,040 seats. 4. Two concurrent reservations cannot both succeed node race-test.js Outputs: Request 1 (Alice): Status 201 Request 2 (Bob): Status 409 SUCCESS: Only one reservation went through 5. README shows query plan before and after index node queryplan.js Outputs: - Before: SEARCH s USING INDEX sqlite autoindex seats 1 (event id=?) - After: SEARCH s USING COVERING INDEX idx seats event status (event id=? AND status=?) Repository: https://github.com/techtuber9988/ticket-sales Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Ticket sales
I built Seatline, a ticket-sales API and browser interface backed by events, seats, and orders tables with foreign keys, indexes, and PostgreSQL support for Vercel, with SQLite available locally. A reviewer can run npm install , configure DATABASE URL , and run npm run seed to create 100 events and 10,000 seats, then open the deployed URL to see the API status, load an event, select a free seat, and reserve it through the UI. The acceptance criteria can be verified with npm run plan to inspect the indexed free-seat query, npm run benchmark to confirm listing performance stays below 200 ms, and npm run race to send two concurrent reservations for the same seat and observe exactly one 201 Created response and one 409 Conflict , proving that PostgreSQL row locking prevents both requests from succeeding. Repository: https://github.com/azizulabedinazmi/SEATLINE-Ticket-sales-API Live: https://seatline.vercel.app/ Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Library loans
Built a library loan-tracking service on Node's built-in node:sqlite module (no external dependencies). Schema has four related tables — books, copies, members, loans — with foreign keys from copies to books and from loans to copies/members. Seeded with 12,000 loans. GET /members/:id/loans returns a member's currently checked-out books, most recently borrowed first, and responds in under 1ms on the full dataset (well under the 200ms bar) once the idx loans member active borrowed index is added — the README shows the real EXPLAIN QUERY PLAN output and timings both before (0.283ms, table scan + sort) and after (0.005ms, direct index search, no sort) adding it. Double lending is blocked at the database layer by a partial unique index (UNIQUE INDEX ... WHERE returned at IS NULL), not application code — test/acceptance.test.js proves this by inserting directly against the database, bypassing the server entirely, and confirming SQLite itself rejects the second active loan. Run node test/acceptance.test.js to verify all five reviewer checks automatically, or node scripts/measure-query-plan.js to regenerate the before/after evidence. Repository: https://github.com/mohammedoomatia-max/library-loans Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Library loans
What I built A Flask + SQLite API for a small library: books, copies, members, loans. GET /api/<member id /loans lists a member's current loans (newest first). POST /api/loans lends a copy. How to verify each criterion 3+ related tables with FKs: app/models.py — copies - books, loans - copies, loans - members. 10,000+ seeded rows: run python seed.py. Seeds 10,500 loans, 1,200 copies, 600 members, 300 books. Under 200 ms: run python run.py, call GET /api/261/loans. Measured 7-26 ms warm (see README). Query plan before/after index: seed.py prints EXPLAIN QUERY PLAN before and after creating ix loans member open; both are in README.md. Double lending blocked by a constraint: partial unique index uq one open loan per copy on loans(copy id) WHERE returned date IS NULL. POST /api/loans returns 409 on violation. Tested: same free copy id posted twice → 201, then 409. Repository link: https://github.com/hassannnn13/Library-loans.git Repository: https://github.com/hassannnn13/Library-loans.git Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Library loans
Repository: https://github.com/sarvarbekbro/library-management-api Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Ticket sales
A ticket sales API. There are three related tables: events, seats and orders. seats.event id references events, and orders.seat id references seats, with foreign keys enforced on every connection. The seed creates 12,000 seats across 5 events plus 1,714 pre-sold orders, for 13,719 rows in total. Node, Express 5 and SQLite Repository: https://github.com/Kam-ino/DevConnect-Internship/tree/main/TicketSales Live: https://devconnect-internship-ticket-sales.onrender.com Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Ticket sales
Repository: https://github.com/R0wanAdel/Ticket-Sales Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Ticket sales
Repository: https://github.com/kiths-bit/ticket-sales-api Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Ticket sales
Repository: https://github.com/saikatdas47/ticket-sales Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Ticket sales
Built a Ticket Sales API — my internship project I just wrapped up a backend project that simulates real ticket reservation: events, seats, and the race-condition problem that shows up the moment two people try to buy the same seat at the same time. Stack: FastAPI · SQLAlchemy · PostgreSQL · Alembic · Docker · pytest What I built: Three related tables (events, seats, orders) with foreign keys and constraints enforced at the database level — not just in application code 12,000 seeded seats across 4 events for realistic performance benchmarking A free-seat listing endpoint, returning in under 200 ms A reservation endpoint that is safe under concurrency 16 automated tests covering endpoints, side effects, and concurrency at both the DB and HTTP layers The two problems that taught me the most: 1. Indexing is not about "adding an index" — it's about making the filter selective. The free-seat query filters on event id and status = 'free'. My first index only covered event id, so PostgreSQL still had to fetch every row and check status on the heap. Adding a composite index on (event id, status) moved both conditions into the index. Heap reads dropped from 23 blocks to 3, and the median query time went from 0.778 ms to 0.159 ms — a 4.9× improvement. But here's the honest part: the endpoint latency barely changed. The database was never the bottleneck — JSON serialization and HTTP overhead dominate the endpoint. Documenting that honestly was more valuable than pretending the index solved everything. 2. Concurrency is a database problem, not an application problem. The naive flow — SELECT → check status == 'free' → UPDATE — allows two requests to both read free before either one writes reserved. Both "win." I fixed it by combining the check and the write into one atomic SQL statement: sql UPDATE seats SET status = 'reserved' WHERE id = :seat id AND event id = :event id AND status = 'free'; PostgreSQL guarantees at most one concurrent transaction can match that WHERE clause. The loser sees rowcount = 0 and returns 409 Conflict. Proved it with two simultaneous HTTP requests. Exactly one 201, exactly one 409, exactly one order in the database. Reproduced on three different seats. I also hit a Windows socket abort under concurrent load — a real infrastructure issue, not a logic bug — and diagnosed it to the SQLAlchemy connection pool. Fixing that with pool pre ping=True was a lesson in production hardening. What I'd take away: The project brief asked for endpoints, an index, and a concurrency-safe reservation. What I actually learned was: How to measure before optimizing Why the database should enforce invariants, not the application How to write evidence, not claims — every number in the README comes from a real captured run The difference between "it works" and "here's proof it works under load" backend fastapi postgresql python concurrency Repository: https://github.com/Ramsha-Anwar/ticket-sales-api Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Library loans
What did you build, and how can a reviewer see that the acceptance criteria are met? I built a Library Loans API using Node.js, TypeScript, Express.js, and PostgreSQL. It manages library books, physical book copies, members, and loan records. The API provides a paginated GET /loans endpoint that returns loan details along with book and member information. I added database constraints to maintain data integrity and a partial unique index to prevent the same physical book copy from having multiple active loans. I seeded the database with 12,000 loan records and optimized the listing query using a composite index on loaned at and id . In my local testing, the query execution time improved from approximately 328.63 ms to 2.25 ms, meeting the under-200-ms performance target in that test environment. The acceptance criteria can be verified as follows: - Database design: Review db/schema.sql to see the related tables, foreign keys, constraints, and indexes. - Data volume: Run SELECT COUNT() FROM loans; to verify that at least 10,000 loan records exist after running the seed script. - Prevention of duplicate active loans: Review the unique active loan per copy partial unique index in db/schema.sql . - API functionality: Start the server and test GET /loans?limit=20&offset=0 . Try different pagination values and invalid inputs to verify validation. - Performance: Review the before-and-after query plans and execution times documented in README.md . These can also be reproduced using EXPLAIN (ANALYZE, BUFFERS) . - Automated testing: Run npm test to execute the API tests. - Build verification: Run npm run build to verify that the TypeScript code compiles successfully. The repository includes setup instructions, database schema and seed scripts, API documentation, performance analysis, and automated tests so the reviewer can reproduce the results locally. Repository: https://github.com/sindhu-dev02/library-loans-api Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Ticket sales
I built a ticket reservation backend using Node.js, Express, and SQLite. Reviewers can verify that all acceptance criteria are met directly in the repository files and README.md: - Database & Seeding: 3 related tables (events, seats, orders) with over 10,000 seeded seat rows are implemented in db.js and seed.js . - Performance (<200ms): Optimized via a compound index ( idx seats event status ) defined in db.js . - Concurrency Control: Race condition prevention is implemented via atomic updates checking result.changes === 0 to return a 409 Conflict if a seat is already taken ( server.js ). - Demonstration: Complete concurrency test commands ( curl ) and expected server responses (Success vs. 409 Conflict) are fully documented in the README.md . Repository: https://github.com/oliviamol/ticketbackend Built for the Verified Backend Internship · a data model and the queries on it