@stevencodes.swe: A few simple lines of code causing random 500s: exists? ➡️ create. Fix it with a unique constraint + INSERT..ON CONFLICT and idempotency keys. #tektok #software #programming #coding
From the practical perspective, it's highly unlikely the same user will be trying to execute some upsert logic in a race conditions scenario from UI.
2025-08-10 04:43:27
55
w01w13 :
Isn't there is now possibility for separate 2 users to create an account with same email address within that timeperiod. I'd rather keep the unique constraint and use transaction to perform the insert, and then handle the response accordingly (e.g. user already exists)
2025-08-11 04:29:30
1
Vorbis :
How would you not have unique index in such case?
2025-08-10 19:26:53
0
Kiddhaxx :
Why upsert? What if two separate users try to use the same email address at the same time? Wouldn’t catching the unique constraint failure be better?
2025-08-10 01:15:11
7
Ameba :
transaction just exist
2025-08-10 06:47:51
0
sam :
on conflict (email) do nothing
is that SQL language or just sudo code?
2025-08-10 09:20:15
1
Nadock :
Not really an issue with the code though, really. It’s an issue with your DB constraints, as you explain. The code could be perfectly valid, eg you want to fast fail and show an error.
2025-08-10 04:12:51
17
elbow ash :
naw, i’m gonna do it with a critical section. by the time we scale to multiple instances it’ll be someone else’s problem❤️
2025-08-10 01:15:18
16
nicksbro :
Hey man. Excellent videos love them. Any resources for practicing issues that only happen at scale and maybe rather harmless on small applications in SQL. Thank you.
2025-08-10 09:53:53
0
Process Control Software :
Very good. Bravo.
2025-08-11 01:21:08
0
Rémi Roy :
or lock using redis
2025-08-12 01:45:23
0
OZA :
Hey your content is super cool. I Would love to see a deep video about this
2025-08-10 03:39:42
2
Absolute :
Let the db do as much data consistency and concurrency checking as possible tha is its job. Don’t leave it all to ORM. Front end dev doesn’t always remember all of the data rules.
2025-08-10 16:15:04
1
jury :
rails mentioned❤️❤️
2025-08-10 15:50:19
1
alexasiricortanay :
Aside from unique index, always have rate limit to prevent race conditions.
2025-08-10 02:10:25
5
Fox🦊Deploy :
Who doesn’t have a distinct index though? But using distributed locking solves these issues
2025-08-11 15:00:40
1
Jèan :
Great vid
2025-08-11 04:56:34
1
AndrewTakker :
CompareAndSet
2025-08-10 10:43:09
0
leuk :
and use an acid database, not all are.
2025-08-10 08:29:32
1
Thunderbuns2000 :
Immediately thought, no transaction. Race here.
2025-08-10 17:50:51
0
Milo Dennison :
@stevencodes | SWE🧑🏻💻 what do you use for your visualizations?
2025-08-10 01:39:03
1
... :
@stevencodes | SWE🧑🏻💻 we could use locking critical section, what do u think? instead of round tripping the database, we could see if the user exists in db in the second request. but i assume this is a rare scenario
2025-08-10 12:06:55
1
gulvar guptar :
💪😎👍
2025-08-10 06:18:36
2
GsusReloded :
🥰
2025-08-10 01:52:02
1
neddy :
also I need your assistance with something, assuming we have one product remaining in our backend and two users click buy at the same time , how do you handle such an issue? and how to avoid such a scenario in future
2025-08-12 03:52:18
0
To see more videos from user @stevencodes.swe, please go to the Tikwm
homepage.