Backend-Focused Full-Stack Developer | GenAI
Joined July 2024
- Tweets6.3K
- Following681
- Followers717
- Likes21.9K
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? 🧵
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 deleted one index from a 100k-row table.
Query time: 0.13ms → 5.3ms.
Then I deadlocked my own database on purpose.
Day 2 of my PostgreSQL backend lab: 5 lessons on what happens when requests collide 🧵
The fix is simple:
Lock resources in a consistent order.
Both transactions:
Product 1 → Product 2
No circular wait → no deadlock.
Sorting IDs before acquiring multiple locks is one practical way to enforce this.
Started my PostgreSQL backend lab today.
The biggest lesson wasn’t learning SQL syntax.
It was understanding that database design is about protecting the correctness of your application before your code even runs.
Here are 4 things that clicked today 🧵
GROUP BY + aggregation is where SQL starts feeling powerful.
SUM(quantity * price)
GROUP BY order_id
Instead of fetching everything and calculating totals in JavaScript, the database can perform the aggregation where the data lives.