The Happy Path
224 posts

The Happy Path
@The_HappyPath
Quick software engineering explainers for things you should've googled by now
Bergabung Aralık 2025
125 Mengikuti440 Pengikut
Tweet Disematkan

@javarevisited Because they make reads significantly faster, and for the right access patterns that tradeoff is worth it. If a column gets read far more than it gets written, paying a small write cost for much faster lookups pays off. It’s a case by case call.
English

@EOEboh Statement 1 is the lie.
Indexes speed up reads but actually slow down writes, because every INSERT, UPDATE, or DELETE has to also update the index structures 👇 x.com/the_happypath/…
The Happy Path@The_HappyPath
Indexes make reads faster, but they aren't free. Every INSERT, UPDATE, and DELETE also has to update every index on that table.
English

Most replies will point at readiness probes, and that solves the "pod not ready yet" case. But 404s can also show up when v1 and v2 simply disagree. A session that hits v1 then v2 will break if routes, payloads, or DB schema changed between them.
The usual fix: ship the code behind a flag, wait until every pod is on v2, then flip it on.
Readiness probes handle "is the pod up". Backward compatibility handles "can v1 and v2 coexist".
English

@javarevisited Because vertical scaling is much simpler to implement. Going horizontal means running a distributed system, which brings things like sharding, cascading failures, and way more operational overhead.
English

@javarevisited The Short Answer: UNION removes duplicate records whereas UNION ALL includes all duplicates

English

@suni_code Compression relies on exploiting data redundancy. A key component of modern compression is Huffman coding 👇
x.com/the_happypath/…
The Happy Path@The_HappyPath
How does a 10GB file become 3GB with zero data loss? A key ingredient: Huffman coding. It gives short codes to common symbols and long codes to rare ones. A simple idea with massive savings. Question: can a file actually end up larger after Huffman coding?
English

@CyberRacheal No code stored means this must be Time-based OTP (TOTP), used by authenticator apps like Authy. The formula is code = f(secret_key, current_time), where secret_key is shared at onboarding. App and server independently compute the same code.

English

@javarevisited COUNT(*) collapses the whole table into a single row. But name could have a different value on every row, so the database has no way to decide which name belongs with that one count.
A possible fix: SELECT name, COUNT(*) FROM users GROUP BY name
English

@javarevisited A TTL cache should be enough to handle this:
On each incoming click:
1. Check clickd:{user_id}:{item_id} in Redis
2. If present, it’s a duplicate within the 5-min window
3. If absent, SETEX it with a 300s expiry

English

- Server gets the OTP input by the user
- Server computes the expected OTP. Not a hash but the actual code that should be sent by the user
- Server compares the code sent by the user to the one it computed, and they should be equal
This approach relies on the Auth app and the server being able to compute the same value for the code
English

@The_HappyPath @suni_code Your diagram has an issue. In the last step you mentioned “if the codes match”. Which code serves matches with? Server gets the otp, recompute the hash and compares with what?
English

@cyber_rekk A. 172.16.11.254
1. Set all the host bits to 1 to find the broadcast address
2. Subtract 1 to find the last usable host IP address

English

@SumitM_X Returns 10 rows: rows 11 through 20. OFFSET 10 skips the first 10, then LIMIT 10 grabs the next 10

English

@cyber_razz It’s A. Each digit is really just 3 bits: one for read (4), one for write (2), one for execute (1). So 7 = 111 = rwx, 5 = 101 = r-x, 0 = 000

English

@cyber_rekk The answer is B. /29.
An IPv4 address is 32 bits. Subtract the prefix length to get host bits: 32 - 29 = 3, which means 2³ = 8 total addresses. Remove network and broadcast, and that leaves exactly 6 usable hosts.

English
















