Replying to @hecodesforme
thanks nice suggestions btw i have already explored the last-unit-in-stock race using concurrent transactions
Replying to @hecodesforme
All three rolled back cleanly. I threw an error intentionally and verified that none of the changes persisted.
Replying to @krrishvardhan @wjshubham @ChaiCodeHQ @Hiteshdotcom @BlazeisCoding @yntpdotme @nirudhuuu
Congratulations bro 🔥
Day 3 takeaway:
Using an ORM isn't just replacing SQL with methods.
It's learning how to shape data, handle missing records, group writes atomically, and reason about failures.
The real test isn't whether the happy path works.
It's what happens when something breaks.
But there's another catch.
A transaction alone doesn't automatically prevent every race condition.
If 2 requests try to buy the last item, both might read stock = 1 before either updates it.
Production code needs concurrency-safe stock updates, not just a transaction.
I wrapped all 3 operations in a Prisma transaction.
Then I deliberately threw an error after the writes.
Result:
Order creation rolled back
Order item creation rolled back
Stock change rolled back
The failed transaction left none of its changes committed.
That's atomicity
Now the important part: checkout.
A purchase involved 3 writes:
Create the order
Create the order item
Decrease product stock
What if the third step fails after the first two succeed?
Without proper transaction handling, the database could be left inconsistent.
Then I queried a user's order history:
User →Orders →Order Items →Products
One nested query returned the related data I needed
I also learned why select matters: an API shouldn't fetch every field when it only needs a few.
Less unnecessary data. More intentional responses.
Using Prisma, I practiced CRUD operations against PostgreSQL:
→ Create and update records
→ Filter, sort, and limit results
→ Fetch only the fields an API needs
The goal wasn't just to make queries work.
It was to understand how database code fits into a backend.
One failed database operation can leave an order half-created.
I tested this with PostgreSQL + Prisma today.
Created an order.
Created its items.
Updated stock.
Then I deliberately threw an error.
What happened next? 🧵

