Why passwords are hashed, not encrypted
Encryption is a two-way street with a key. Hashing is a one-way mathematical trapdoor. Why speed is the enemy of secure passwords.
The engineering questions you get asked, and the bugs you actually hit. Drawn, one mechanism at a time, in the order the videos ship.
Encryption is a two-way street with a key. Hashing is a one-way mathematical trapdoor. Why speed is the enemy of secure passwords.
Your server returned 200 OK, Postman works fine, and your frontend console is red. CORS is not a server error; it is a browser security sandbox.
You changed the price an hour ago and somebody just paid the old one. HTTP gives a server exactly one way to remove something from a cache, and it is a side effect rather than a command.
The page said welcome back, with somebody else's name on it. Four questions decide whether something in the path may answer instead of your server — and the default, when you say nothing at all, is not 'don't cache'.
You asked for a name and a price and thirty-eight fields came back. Every difference between the two is one trade seen from a different side — and the caching bill is where it comes due.
Every request came back 200 and nobody could buy anything. The last two digits have no categorisation role at all — and an error inside a success is a lie three separate systems believe.
REST is six constraints in one chapter of one dissertation, not a synonym for JSON over HTTP — and the spec's own example of getting it wrong is a link a crawler follows to delete your rows.
A relational database stores facts once and assembles the answer when you ask; a document store keeps the answer assembled and pays when it changes — and joins, schema, sharding and consistency are that one trade seen from four sides.
An isolation level is a list of what is still allowed to happen to you — and the half a ninety-second video has to cut: the retry loop serializable makes you write, the statement that has to come first, the anomaly the standard never named, and what your database's default actually is.
Four promises, one disaster each — and the setting that makes an application less reliable the moment you turn it up, unless you also write the retry loop nobody mentions.
A hundred sub-millisecond queries, a four-second page, and the two cuts the video could not afford: a batched second query is two points in time, and a thousand ids in an IN list is a problem of its own.
The planner never ignored it — it priced it. The two things the video could not say safely, then everything else it cut: index-only scans, partial and multicolumn indexes, trigrams, BRIN, statistics, HOT updates, bloat, and what LIMIT does to a plan.