DEV Community: HkSolDev

Authentication From First Principles: How Login Actually Works, From Google Sign-In to Passkeys

HkSolDev — Thu, 15 Oct 2026 00:51:15 +0000

Understanding authentication, OAuth, PKCE, sessions, cookies, and passkeys — one problem at a time.

Think about how many websites you use every day.

You watch videos on YouTube, browse Instagram, send messages, or work on your favorite applications.

Most of the time, you don't even think about authentication. You open a website, and somehow, it already knows who you are.

Your profile is there. Your settings are there. Your saved content is there.

But have you ever wondered:

How does a website actually know it's you?

And more importantly, how does it know that someone else isn't pretending to be you?

That's where authentication comes in.

When I started exploring authentication, I realized something interesting. We use login systems almost every day, but there's quite a lot happening behind that simple Sign In button.

Google Sign-In, OAuth, PKCE, cookies, sessions, passkeys — you've probably heard some of these terms.

But why do we need so many things just to log someone in?

Instead of memorizing definitions, let's build an authentication system in our heads, starting with the simplest possible solution.

Every time we encounter a problem, we'll figure out why it happens and introduce the mechanism designed to solve it.

By the end, we'll understand not just how authentication works, but why it works that way.

1. Why Do We Need Login in the First Place?

Imagine you're building a website like YouTube.

People can visit your website and watch videos.

So far, so good.

But now someone wants to save videos to a playlist, subscribe to a channel, or receive personalized recommendations.

That creates a problem.

How do you know which playlist belongs to which person?

Suppose two people are using your application.

One person has saved 20 videos, and the other has saved 50.

Your application needs to recognize them so it can show each person the correct data.

You might think:

"That's simple. I'll just ask them for their username."

Okay, but what stops me from entering someone else's username?

Nothing.

If your application simply trusts whatever name someone enters, anybody could pretend to be anybody.

So knowing someone's name isn't enough.

We need a way for the user to prove their identity.

And that's the fundamental problem authentication solves.

Authentication vs. Authorization

Before going further, we need to understand two concepts that sound similar but solve different problems.

Let's use a driving license as an example.

Imagine someone asks you to prove who you are.

You show them your driving license.

They check your identity.

That's similar to authentication.

Authentication answers one question:

Who are you?

Now imagine you want to drive a heavy commercial vehicle.

Your license might prove your identity, but does it mean you're allowed to drive every type of vehicle?

Of course not.

Your license may permit you to drive a car but not a heavy truck.

That's where authorization comes in.

Authorization answers a different question:

What are you allowed to do?

The same thing happens inside an application.

Suppose you log in to YouTube.

The website recognizes your account. You're authenticated.

But that doesn't mean you can delete someone else's videos or modify their account settings.

You're authenticated, but you aren't authorized to perform those actions.

Authentication proves who you are. Authorization determines what you can access or do.

And here's something important: authentication alone doesn't make an application secure.

Even after a user logs in successfully, the backend must check whether that user is authorized to access the requested resource.

Now that we understand why login exists, let's figure out how to implement it.

2. How Do We Actually Authenticate Someone?

There are several ways to authenticate users.

We could ask them to create a password. We could let them sign in using Google. Or we could use something called a passkey.

All three can help establish someone's identity, but they work differently.

Let's start with something almost everyone recognizes:

Continue with Google.

You've probably clicked that button hundreds of times.

But what actually happens when you click it?

Our First Attempt: Just Ask Google

Imagine we're building our own application.

Instead of managing passwords ourselves, we want Google to authenticate users for us.

Our first idea might look like this:

Our Application
       |
       v
     Google
       |
       v
User signs in
       |
       v
Google sends a token
       |
       v
Our Application

It sounds reasonable.

Google already knows the user, so why not let Google verify their identity and send us proof?

But there's a problem.

How should Google send that proof back to our application safely?

To understand the solution, we need to look at two protocols that frequently work together.

OAuth 2.0 vs. OpenID Connect

You've probably heard that Google Sign-In uses OAuth.

That's true, but there's an important distinction.

OAuth 2.0 is primarily about delegated authorization.

For example, imagine an application wants permission to read certain information from your Google Calendar.

You shouldn't have to give that application your Google password.

Instead, Google can ask whether you want to grant the application specific permissions.

The application can then receive an access token for those permitted operations.

But remember our original problem?

We're not necessarily trying to access the user's Google Calendar.

We're trying to figure out who the user is.

That's where OpenID Connect (OIDC) comes in.

OIDC adds an identity layer on top of OAuth 2.0.

It allows an application to authenticate a user and receive an ID token, containing information about the authenticated identity.

So when we talk about Google Sign-In, we're usually talking about an OpenID Connect authentication flow built on OAuth 2.0.

Don't worry about remembering the terminology yet.

The important distinction is:

An access token is intended for accessing protected resources. An ID token is intended to communicate information about authentication and identity to the client application.

Now let's return to our application.

We know Google can authenticate the user.

But how do we safely retrieve the result?

3. The Authorization Code: Why Not Send Tokens Directly?

Imagine a user clicks Continue with Google.

Our application redirects their browser to Google.

They sign in, and Google needs to send the result back.

Our first thought might be:

"Why doesn't Google simply put the token in the redirect URL?"

Something like:

https://ourapp.com/callback?token=...

But URLs can end up in places we don't want sensitive credentials to appear, including browser history, logs, and other systems.

We don't want to unnecessarily expose important tokens during browser redirects.

So how can Google tell our application that authentication succeeded without putting the final tokens in the redirect?

The Solution: An Authorization Code

Instead of sending the final tokens through the redirect, Google sends a temporary authorization code.

The flow becomes:

User clicks "Continue with Google"
               |
               v
       Redirect to Google
               |
               v
        User authenticates
               |
               v
 Google redirects back with
      Authorization Code
               |
               v
   Our application exchanges
   the code directly with Google
               |
               v
       Tokens are returned

The authorization code is short-lived and intended for a limited exchange.

Our backend sends it to Google's token endpoint, together with the other required information, to obtain tokens.

This is much better than putting the final tokens in the browser redirect.

But notice something.

We've introduced a new credential: the authorization code.

And that creates another question.

What if someone tries to interfere with the login callback?

4. The State Parameter: Did We Actually Start This Login?

Let's imagine our application receives a request:

https://ourapp.com/callback?code=xyz123

There's an authorization code in the URL.

But how does our application know that this callback belongs to a login attempt started by the current user?

What if someone tries to trick another person's browser into completing an authentication flow that the person didn't initiate?

This is a form of login-related CSRF risk.

We need a way to connect an incoming callback to the original authorization request.

The Solution: `state`

Before sending the user to Google, our application generates a random value.

Let's call it:

state = random_value_123

Our application securely associates this value with the user's authentication attempt.

Then it includes that value in the authorization request sent to Google.

When Google redirects the browser back, it returns the same state.

Our application checks:

State we originally created
            ==
State returned by Google

If they match, the response is associated with the login flow we started.

If they don't match, we reject the callback.

In a real implementation, state must be unpredictable and bound to the correct browser-initiated flow. Simply trusting any returned value would defeat its purpose.

So state helps us protect the integrity of the login flow.

But we're still not finished.

Because state answers one question:

Does this callback belong to a login flow we started?

It doesn't, by itself, solve every problem involving a stolen authorization code.

And that brings us to PKCE.

5. PKCE: What If Someone Steals the Authorization Code?

We introduced authorization codes because we didn't want to expose the final tokens during the redirect.

But an authorization code is still valuable.

Suppose an attacker somehow obtains a valid authorization code.

What stops them from trying to exchange that code for tokens before the legitimate application does?

That's the problem PKCE helps solve.

PKCE stands for Proof Key for Code Exchange.

The name sounds complicated, but the idea is surprisingly simple.

Instead of allowing the authorization code alone to be sufficient for redemption, we make the client prove that it possesses a secret value associated with the original authorization request.

Step 1: Create a Secret

Before redirecting the user to Google, the client generates a cryptographically random value.

This is called the code verifier.

Think of it as a secret the client must remember during this particular login attempt.

For example:

Code Verifier = long_random_secret

The client doesn't send this verifier in the initial authorization request.

Instead, it derives another value from it.

Step 2: Create the Code Challenge

Using the recommended S256 method, the client hashes the code verifier with SHA-256 and applies the required URL-safe encoding.

This produces the code challenge.

Conceptually:

Code Verifier
      |
      v
SHA-256 + URL-safe encoding
      |
      v
Code Challenge

Here's the interesting part.

It's easy to create the challenge from the verifier.

But knowing the challenge doesn't practically allow someone to recover a properly generated random verifier.

The client sends the challenge to Google when starting authorization.

Google associates it with that authorization request.

Step 3: Exchange the Authorization Code

After the user signs in, Google redirects the browser back with the authorization code.

Now the client wants to exchange that code for tokens.

But this time, the request must also include the original code verifier.

Google derives the challenge from that verifier and compares it with the challenge associated with the authorization code.

If they match, the PKCE check passes.

Otherwise, the code exchange is rejected.

Why Does This Help?

Imagine someone steals the authorization code but doesn't have the corresponding code verifier.

The code alone is no longer enough.

They need the verifier associated with the original authorization request.

That's the protection PKCE adds.

Of course, if an attacker compromises the verifier too, PKCE cannot magically stop them. It also doesn't replace HTTPS, client authentication where required, or other OAuth security checks.

But it closes an important gap.

Now we have three separate pieces that make much more sense together.

The authorization code keeps the final tokens out of the authorization redirect.

The state parameter helps connect the callback to the login attempt our application initiated.

And PKCE makes a stolen authorization code insufficient for redemption without the associated verifier.

Each one solves a different problem.

Now let's say all these checks pass.

Google successfully authenticates the user.

What happens next?

6. Google Knows Who You Are. But How Does Our Application Know?

At this point, Google has authenticated the user, and our application has successfully exchanged the authorization code.

For an OpenID Connect login, Google returns an ID token.

But should our backend immediately trust whatever identity information it receives?

Of course not.

The backend first needs to validate the ID token.

This includes checking its cryptographic signature, whether it was issued by the expected provider, whether it was intended for our application, and whether it has expired.

Depending on the authentication flow, we may also need to verify other values, such as a nonce, which helps bind the ID token to the authentication request.

Once the token passes the required checks, our application can trust the verified identity claims.

An important claim is sub, which is Google's stable identifier for that user.

Why is that useful?

Because email addresses can change, and they're not always a reliable primary identifier for an external identity.

We can associate the Google account's verified identifier with a local user record in our database.

For example:

Google authenticates user
           |
           v
Our backend verifies ID token
           |
           v
Read Google's user identifier
           |
           v
Find existing application user
       or create one

Now our application knows which local account belongs to the authenticated Google user.

Great!

But here's another problem.

Does the User Have to Sign In with Google on Every Request?

Imagine you're watching YouTube.

You open the homepage, search for a video, open a channel, and then save something to a playlist.

Does YouTube have to send you through the complete Google authentication process for every action?

That would be incredibly inconvenient.

And for our application, repeatedly starting a new external login flow would be unnecessary.

We already verified the user's identity.

Now we need a way to remember that authentication across subsequent requests.

That's where sessions come in.

7. Sessions: How Does a Website Remember You're Logged In?

Let's think about the problem.

When you visit a website, your browser sends an HTTP request.

The server processes that request and returns a response.

Later, you click another page or perform another action.

Your browser sends another request.

But HTTP requests don't automatically remember that you authenticated earlier.

So how does the server connect all those requests to the same logged-in user?

The Solution: Create a Session

After successfully authenticating someone, our backend creates a session.

Think of a session as a record that says:

"This user successfully authenticated, and this login is currently valid."

A simplified session record might look like this:

Session
-------------------------
Session ID: random_abc123
User ID:    user_42
Created:    10:00 AM
Expires:    11:00 AM

In practice, the session identifier must be generated using a secure random number generator and should be much harder to guess than our example.

The backend can store the session in a database or a session store such as Redis.

But there's a new problem.

The backend has created a session.

How does the browser know which session belongs to it?

Cookies: The Browser's Session Identifier

Our backend can send a cookie containing an unpredictable session identifier.

For example:

Set-Cookie: session=abc123;
            HttpOnly;
            Secure;
            SameSite=Lax;
            Path=/

The browser stores the cookie.

Now, whenever the browser makes an appropriate request to our application, it automatically includes that cookie.

The backend can look up the corresponding session and determine which user is authenticated.

The process looks like this:

Browser
   |
   | Request + Session Cookie
   v
Backend
   |
   | Look up session
   v
Database / Redis
   |
   | Session belongs to user_42
   v
Backend identifies user
   |
   | Check authorization
   v
Return requested data

Notice something important.

The browser usually doesn't need to store the user's full information inside the session cookie.

For this server-side session design, it only needs to hold an opaque identifier.

The actual session state stays on the server.

That's useful because the server can expire or revoke the session independently of the browser.

Also, storing a session in Redis rather than a database doesn't fundamentally change how authentication works.

It's a storage and performance decision.

At this point, our user can browse the application without signing in again on every request.

Problem solved?

Not completely.

Because we've just introduced a new credential.

The session cookie.

And if someone gets access to a valid session cookie, they may be able to use it to impersonate the user.

So how do we protect it?

8. HttpOnly: What If JavaScript Tries to Steal the Cookie?

Imagine you're logged into our application.

Your browser contains a valid session cookie.

Now suppose an attacker manages to inject malicious JavaScript into one of our pages.

This could happen because of an XSS vulnerability.

XSS stands for Cross-Site Scripting.

Depending on the vulnerability, malicious JavaScript may be able to read information from the page or act within the user's authenticated browser session.

If our session cookie is accessible through JavaScript, an attacker might try to read it.

For example:

document.cookie

We don't want ordinary page scripts to have access to our session credential.

The Solution: HttpOnly

We can mark the session cookie with the HttpOnly attribute.

Set-Cookie: session=abc123; HttpOnly

This tells the browser not to expose the cookie through normal JavaScript APIs such as document.cookie.

That's helpful.

But here's a question I had when learning about this:

If JavaScript can't read the cookie, how does the application send it to the backend?

The answer is that JavaScript doesn't need to read it.

The browser handles cookies.

When a request matches the cookie's scope and applicable browser rules, the browser can attach the cookie automatically.

So HttpOnly restricts JavaScript access without preventing normal cookie-based authentication.

However, there's an important limitation.

HttpOnly doesn't completely solve XSS.

Malicious JavaScript running on our site may still be able to perform actions as the authenticated user, even if it cannot directly read the session cookie.

We still need proper XSS prevention.

But the cookie is now better protected against direct theft through JavaScript.

Great.

Unfortunately, that automatic cookie behavior creates another problem.

9. CSRF: Can Another Website Use My Logged-In Session?

Remember how the browser automatically attaches cookies?

That's convenient for us.

But what if another website tricks the browser into sending a request to our application?

Let's use a simple banking example.

Imagine you're logged into:

https://bank.com

Your browser has a valid session cookie for that website.

Now you visit a completely different website.

The second website contains malicious content that tries to submit a request to bank.com.

The attacker cannot normally read your bank's HttpOnly cookie.

But under certain conditions, they may be able to make your browser send a request that includes it.

If the bank accepts that request without appropriate protections, it might perform an action you never intended.

And here's the important part:

The attacker didn't need to steal your cookie. Your browser supplied it.

This is the fundamental problem behind Cross-Site Request Forgery, or CSRF.

So how do we prevent unwanted requests from using our authenticated session?

First Defense: SameSite Cookies

Cookies can use a SameSite attribute.

This tells the browser when to include them in cross-site situations.

There are three commonly used values.

SameSite=Strict

The browser won't send the cookie with cross-site requests.

This provides strong cross-site restrictions, but it can sometimes make legitimate navigation less convenient.

SameSite=Lax

This is often a practical middle ground.

It generally prevents cookies from being included in cross-site POST requests while allowing them on certain top-level navigations using safe HTTP methods, such as GET.

SameSite=None

This allows cookies in cross-site contexts, subject to browser policies.

It requires the Secure attribute.

Applications using cross-site cookies need appropriate additional protections.

For many traditional web applications, SameSite=Lax offers useful protection.

But should we rely on SameSite alone for every sensitive operation?

Not necessarily.

Second Defense: CSRF Tokens

Imagine an attacker can cause your browser to send a request to the bank.

But what if the bank requires something additional?

Something that the legitimate application can include, but a malicious website cannot normally obtain.

That's the idea behind a CSRF token.

The application generates a secure, unpredictable value and makes it available to its legitimate frontend through an appropriate mechanism.

For protected actions, the frontend must send that value with the request.

The server validates it.

Conceptually:

Session cookie + Valid CSRF token
                |
                v
       Request can continue

But:

Session cookie + Invalid CSRF token
                |
                v
          Reject request

A malicious website might cause a browser to attach cookies, but browser security rules normally prevent that website from reading the legitimate application's CSRF token.

That's why this additional value can help protect sensitive requests.

Applications may also use Origin checks and other CSRF defenses depending on their architecture.

And one more rule matters:

Never make a state-changing operation depend on an unsafe use of GET.

A request that deletes an account or changes a password shouldn't be triggered simply by visiting a URL.

What About the Secure Cookie Attribute?

There's another important cookie setting:

Secure

This tells the browser to send the cookie only over secure HTTPS connections.

So now the three attributes make sense.

HttpOnly restricts JavaScript access.

Secure restricts transmission to HTTPS.

SameSite controls cross-site cookie sending.

They don't solve the same problem.

Each protects a different part of our authentication system.

Now that our session cookie is better protected, let's return to the user's experience.

Because there's another problem we haven't addressed.

How long should a session remain valid?

10. Session Expiration: Should a User Stay Logged In Forever?

Imagine you're watching YouTube.

You've been watching videos, exploring different channels, and saving videos to your playlists.

Then you try to like a video.

Suddenly, you're asked to sign in again.

That's frustrating.

You were actively using the website. Why did it suddenly forget who you were?

In a real application, an expired login wouldn't necessarily interrupt public video playback, but it could interrupt account-specific actions such as commenting, saving playlists, or managing subscriptions.

Now imagine you're building that application.

You need to decide how long a session should remain valid.

Let's say every session expires after one hour.

That sounds simple.

But what happens when a user is still actively using the website after that hour?

If we force them to log in again every time, the experience becomes annoying.

So we need something better.

Sliding Expiration: Extend Active Sessions

What if we extend the session while the user is actively using the application?

That's called sliding expiration.

Imagine a session has a one-hour inactivity timeout.

The user authenticates at 10 AM.

Initially, the session expires at 11 AM.

But at 10:30 AM, the user interacts with the application.

Our server can renew the session's inactivity expiration.

Now it might expire at 11:30 AM.

If the user continues interacting with the application, the expiration can move forward again.

The idea is simple:

Keep active users signed in, while allowing inactive sessions to expire.

The backend must update the relevant server-side session expiration and, when necessary, renew the browser cookie too.

We don't necessarily need to perform this update on every request. Applications can renew periodically to avoid unnecessary database writes.

This improves the user experience.

But can you see the problem?

What If the User Keeps Coming Back Forever?

Imagine someone uses YouTube every day.

Every time they return, the session gets extended.

One day becomes a week.

A week becomes a month.

And a month becomes a year.

Should that session remain valid forever?

Probably not.

Especially if someone else has managed to obtain the session credential.

That's where another concept comes in.

Absolute Session Expiration

An absolute expiration places a maximum lifetime on a session, regardless of activity.

For example, an application might use:

Inactivity timeout: 1 hour

Absolute lifetime: 30 days

These are illustrative values, not universal security recommendations.

A session can be renewed while it's active, but it cannot extend beyond the absolute expiration.

Once the maximum lifetime is reached, the application requires the appropriate fresh authentication before establishing a new fully authenticated session.

This is the balance we're trying to achieve.

Sliding expiration improves convenience.

Absolute expiration limits how long the same authentication can remain valid.

But here's something I initially wondered:

"Why not just create a new session automatically when the old one reaches its absolute expiration?"

After all, that would avoid interrupting the user.

It sounds like a clever solution.

Until we consider what happens if someone steals the session.

11. What If Someone Steals Your Session Cookie?

Imagine your session identifier is:

session = ABC123

Your browser sends that cookie to the server.

The backend checks the session store.

It finds the session, confirms that it's still valid, and identifies your account.

Everything works.

But now imagine someone steals a copy of that cookie.

They send:

session = ABC123

The backend checks the same session store.

The session exists.

It hasn't expired.

It hasn't been revoked.

So the backend may accept it.

Now we have a serious problem.

Both the real user and the attacker can present the same valid session credential.

How does the server know who's actually using it?

Based on the session cookie alone, it generally can't.

That's one of the most important things to understand about session-based authentication.

A valid cookie proves possession of a session credential. It doesn't necessarily prove that the person presenting it is the legitimate account owner.

Why Not Just Create a New Session Token?

Suppose we regularly replace the old session identifier with a new one.

This is called session rotation.

Rotation is useful. For example, replacing a session identifier after successful authentication helps protect against session fixation attacks.

But does rotating a stolen session automatically solve session hijacking?

Not necessarily.

If an attacker can use the same session credential as the real user, simply issuing another credential doesn't tell the backend which person is legitimate.

In some situations, the attacker might even obtain the newly issued credential.

So rotation is a security tool, not a guaranteed method of detecting impersonation.

We need something different when the risk is high.

The Solution: Reauthentication

Let's return to YouTube.

Imagine you're watching a video and click the Like button.

Should YouTube ask you to verify your identity again?

That would be ridiculous.

Now imagine you're trying to change your password, remove an important security method, or delete your account.

Those actions are much more sensitive.

What if the application asks for fresh proof that you're the legitimate account owner before allowing them?

That's reauthentication, sometimes called step-up authentication when stronger or additional authentication is required.

The application might ask you to authenticate again using a password, passkey, or another suitable method.

The exact choice depends on the application's risk and the available authentication methods.

The important distinction is that we're not merely checking whether the existing session is valid.

We're asking for new proof of identity.

That helps reduce the risk of someone who possesses only a stolen session cookie performing highly sensitive operations.

It isn't perfect protection against every compromised-device attack, but it's much stronger than blindly trusting the old cookie.

What Happens When the User Logs Out?

Let's consider another everyday situation.

You use a website on a shared computer and click Log Out.

Should the server simply delete the cookie from that browser?

No.

Imagine someone had copied the cookie before you logged out.

Clearing the cookie from your browser wouldn't invalidate their copy.

The server must also revoke or delete the corresponding session.

Then even if someone presents the old identifier, the backend rejects it.

What If You're Logged In on Multiple Devices?

You might be signed in on your phone, laptop, and tablet.

Ideally, each device has its own session.

That gives the application more control.

If you lose your laptop, you may want to revoke that device's session without logging out everywhere else.

Or you may want a Log Out of All Devices feature that invalidates every active session.

Both are easier when the server tracks sessions individually.

What If the Cookie Expires but the Session Still Exists?

There's one more detail worth understanding.

Browser cookie expiration and server-side session expiration are not the same thing.

Imagine your browser deletes its session cookie because the cookie expired.

But the corresponding session record still exists in Redis or your database.

The browser no longer has the identifier needed to use that session.

So even though the server-side record exists, the user may appear logged out.

The backend cannot simply recognize that browser as the old session without another valid credential.

Now imagine thousands of abandoned sessions sitting in the database.

We don't want those records accumulating forever.

Applications can periodically delete expired sessions, use TTL-based expiration where supported, or combine those approaches.

This keeps session storage manageable.

At this point, we've built a fairly complete session system.

Our application can authenticate someone, remember their identity, maintain active sessions, expire old ones, revoke access, and request fresh authentication for sensitive actions.

But notice something.

We're still depending on a user having some way to prove their identity initially or when reauthentication is required.

Google Sign-In is one option.

A traditional password is another.

And passwords introduce a whole new collection of problems.

What if we could solve those too?

12. Passwords: Why Is Something So Common Also So Problematic?

Let's forget Google Sign-In for a moment.

Imagine you're registering on a new website.

It asks you to create a password.

Okay, no problem.

You enter one.

Tomorrow, you register on another website.

Another password.

The day after that, you register on three more websites.

Three more passwords.

Now multiply that by every application you use.

Email, social media, shopping, streaming, banking, developer tools, and dozens of other services.

Are you really going to remember a different, strong password for every website?

Most people won't.

And that's where the trouble begins.

Problem 1: Reusing Passwords

Imagine you use the same password for five websites.

It seems convenient.

You only need to remember one password.

But what happens if one of those websites suffers a data breach and your password is exposed?

An attacker may try that same password on your other accounts.

Suddenly, a breach at one website threatens accounts on completely different websites.

This is one reason password reuse is dangerous.

Problem 2: Weak Passwords

Okay, maybe we'll use different passwords.

But remembering all those passwords is difficult.

So some people choose things that are easy to remember.

Their name.

Their birthday.

A familiar word.

A simple pattern.

Unfortunately, those passwords may also be easier for attackers to guess.

Attackers can attempt password guessing, use leaked password lists, or try automated attacks against poorly protected authentication systems.

Of course, websites should implement protections such as rate limiting and detection of suspicious login activity.

But weak passwords remain a problem.

Problem 3: Even a Strong Password Can Be Compromised

Now suppose you do everything correctly.

You generate a long, random password.

You don't reuse it anywhere.

You don't share it.

Surely you're safe?

You're much safer, but there's still a problem.

The website itself could be compromised.

Websites shouldn't store plaintext passwords. They should store passwords using appropriate salted password-hashing algorithms, such as Argon2id.

However, attackers who steal a password database may attempt offline guessing against those hashes.

Strong, unique passwords are much harder to recover, but a breach still creates risk.

And passwords can also be stolen through phishing.

Imagine a fake website that looks exactly like Google's login page.

You enter your password because everything looks familiar.

But you've just given the password to an attacker.

A strong password doesn't protect you if you willingly enter it into the wrong website.

So now we have several problems.

Passwords are difficult to remember, tempting to reuse, sometimes easy to guess, and vulnerable to phishing.

Even with good password storage and a strong password, security still depends on keeping a shared secret protected.

Can We Improve This?

What if we could authenticate someone without asking them to remember a password?

What if every website had its own cryptographic credential that wasn't based on a memorable phrase?

And what if a website could verify our identity without storing a password or any equivalent secret that could be used to impersonate us?

That sounds much better.

And this brings us to passkeys.

13. Passkeys: What If We Didn't Need Passwords?

Let's start with the problem we're trying to solve.

Traditional password authentication depends on a secret.

You know the password, and the website stores information that lets it check whether you entered the correct password.

Passkeys approach authentication differently.

Instead of inventing a password, your device or credential manager creates a pair of cryptographic keys.

One is called the private key.

The other is called the public key.

Together, they're known as a key pair.

Now here's the important part.

The private key remains protected by your authenticator or passkey manager.

The public key is shared with the website.

For example:

Your Device / Passkey Manager
-----------------------------
Private Key
(Kept protected)


Website Database
-----------------------------
Public Key
(Used for verification)

At first, that might sound strange.

Why are we giving the public key to the website?

And how can the website verify us without knowing the private key?

To understand that, let's use a simple analogy.

Think of a Unique Cryptographic Signature

Imagine you have a special stamp.

Only you can use it to produce a particular kind of signature.

Other people have a way to check whether a signature was created using your stamp.

But being able to check the signature doesn't mean they can create a valid one themselves.

That's roughly how digital signatures help with passkey authentication.

The private key produces a cryptographic signature.

The corresponding public key verifies that signature.

Importantly, the public key doesn't decrypt the signature.

It checks its mathematical validity.

Here's the idea:

Private Key
     |
     | Signs a message
     v
Digital Signature
     |
     | Verified using
     v
Public Key

The website doesn't need your private key.

It only needs the corresponding public key to verify that the expected private key was used.

And generating the public key from the private key doesn't mean that someone can practically reverse the process and recover the private key.

This is the foundation of passkey authentication.

What Problems Have We Solved?

Think back to our password problems.

First, the user no longer needs to invent and memorize a password for the website.

Second, because cryptographic credentials are generated rather than chosen as memorable phrases, we avoid the problem of someone selecting their birthday or name as their password.

Third, passkeys are created for a particular website or service. We're not reusing the same password across unrelated websites.

Fourth, the server stores a public key rather than a password or password hash.

Even if someone steals that public key from the database, they cannot use it alone to generate valid signatures.

That doesn't make a database breach harmless. Other information in the database could still be sensitive.

But it avoids exposing a reusable password credential.

Pretty interesting, right?

We've replaced the need to remember a secret with the ability to prove possession of a private key.

But now we have a new question.

How does the website know which public key belongs to which user?

14. Creating a Passkey: How Does the Website Know It's Yours?

Imagine you're creating an account on a new website.

You click:

Sign Up with Passkey

What should happen?

Our first thought might be:

"Generate a key pair, store the public key in the database, and keep the private key on the user's device."

That sounds correct.

But we need to think a little more carefully.

Suppose you're registering using an email address.

What's stopping someone else from entering your email address and registering their own passkey?

They would have a perfectly valid private key.

And the website would have the matching public key.

The cryptography would work.

But that doesn't mean they own your email address or your existing account.

That's an important distinction.

A valid key pair can prove possession of the private key.

It doesn't automatically prove ownership of an email address or permission to control an existing account.

First, Establish Which Account Owns the Passkey

For an existing account, the website should normally require appropriate authentication, and sometimes fresh reauthentication, before allowing a new passkey to be added.

For a new account, the website can create the account through a passkey-first registration flow.

If that new account claims ownership of an email address, the website should verify the email address before trusting the claim.

This is separate from the passkey cryptography.

Now we know which account the new credential should belong to.

But how do we create and register it securely?

That's where WebAuthn comes in.

15. WebAuthn: How Does Passkey Registration Actually Work?

WebAuthn stands for Web Authentication.

It's a web standard that lets applications use authenticators for public-key authentication.

Passkeys are based on this technology.

Let's imagine you're signed in to our application with Google and want to add a passkey.

Step 1: The User Clicks "Create Passkey"

Our backend already knows which account is requesting the operation because the user has an authenticated session.

After the necessary authorization and reauthentication checks, the backend prepares a passkey registration request.

It generates a fresh, random challenge and includes the information needed for the new credential.

Step 2: The Browser Requests Credential Creation

The application passes the registration options to the browser using WebAuthn.

The browser coordinates with an appropriate authenticator.

That might be your phone's built-in authenticator, your computer, a hardware security key, or a passkey manager.

The authenticator creates a new cryptographic key pair.

The private key stays protected by the authenticator or credential manager.

The public key can be returned to the application.

Step 3: The Device May Ask You to Verify Yourself

You might see a familiar prompt asking for your fingerprint, face recognition, or device PIN.

We'll come back to why this matters.

For now, think of it as the device checking whether it should allow you to create or use the credential.

Step 4: The Website Verifies Registration

The browser returns credential information to our application.

The backend validates the WebAuthn registration response.

This includes checking the challenge, the expected website identity, and other required properties of the response.

Depending on the application's policy, it may also examine authenticator attestation information.

If the checks succeed, the backend stores the credential information, including the public key and credential identifier, under the correct user account.

The overall flow looks like this:

User clicks "Create Passkey"
              |
              v
Backend generates challenge
              |
              v
Browser invokes WebAuthn
              |
              v
Authenticator creates key pair
              |
              v
Private key remains protected
              |
              v
Browser returns registration data
              |
              v
Backend validates registration
              |
              v
Public key + credential ID
saved under the user account

Now our website has a registered public key associated with the user's account.

The private key wasn't sent to our backend.

Great.

But we've only registered the passkey.

How do we use it when the user comes back tomorrow?

16. Logging In with a Passkey: Proving You Have the Private Key

Imagine you open the website the next morning.

You click:

Sign In with Passkey

The website already has your registered public key.

Your authenticator has access to the corresponding private key.

So how does the website confirm that the private key is actually being used?

The simplest idea might be:

"Why doesn't the device just sign a fixed message?"

For example:

I am user_42

The server could verify the signature.

But there's a problem.

What If Someone Reuses an Old Signature?

Suppose the device signs the same message every time.

An attacker somehow captures a valid signed response.

Later, they send exactly the same response to the server.

If the server accepts the same response repeatedly, the attacker might authenticate without possessing the private key.

This is a replay attack.

The signature was valid when it was created.

The problem is that the attacker is reusing an old authentication response.

How do we stop that?

The Solution: A Fresh Challenge Every Time

Instead of asking the device to sign the same message repeatedly, our server generates a fresh random challenge for each authentication attempt.

Imagine the server sends:

Challenge: X7K92_RANDOM_VALUE

The authenticator signs the required authentication data, which is cryptographically bound to that challenge and the request context.

The browser returns the authentication response.

The backend retrieves the stored public key and verifies the response.

It also checks that the challenge matches the one issued for this attempt, along with the required website and authenticator information.

Conceptually:

         WEBSITE
            |
            | Fresh random challenge
            v
       YOUR DEVICE
            |
            | Verify user if required
            |
            | Sign authentication data
            | with private key
            v
     Signed Response
            |
            v
         WEBSITE
            |
            | Verify using public key
            |
            | Check challenge
            |
            | Check website identity
            v
     Authentication succeeds

The crucial point is that the private key never needs to be sent to the website.

The backend verifies the cryptographic proof using the public key it already registered.

And because each authentication attempt uses a fresh challenge, an old response cannot simply be replayed successfully.

Now we have a working passkey login flow.

But something interesting is still missing.

What if the website itself is fake?

17. Phishing Resistance: What If Someone Copies Google's Login Page?

Let's return to the password problem.

Imagine an attacker creates a website that looks almost identical to Google's login page.

Same colors.

Same layout.

Same buttons.

Even the same logo.

You might not immediately notice the difference.

But the actual domain is:

g00gle.com

Notice the zeros instead of the letter O.

With a traditional password, you might accidentally type your credentials into that fake website.

And the attacker could capture what you typed.

But what happens with a passkey?

Passkeys Are Bound to Website Identity

Passkeys aren't simply keys that work on any website requesting a signature.

WebAuthn credentials are associated with a website identity called a Relying Party ID, usually abbreviated as RP ID.

This is based on a domain name.

The browser and authenticator enforce rules about which websites can use credentials associated with that RP ID.

The real Google website and a lookalike domain such as g00gle.com are not the same relying party.

So a credential registered for the real Google service won't normally be offered for authentication to the fake domain.

The server also verifies the expected origin and RP ID information as part of WebAuthn authentication.

That's an important security property.

A fake website can copy the appearance of a login page. It cannot simply become the legitimate website's domain by copying its design.

With passwords, users often need to notice phishing attempts themselves.

With properly implemented passkeys, the browser and authenticator help enforce that credentials are used only for their intended website.

This is called phishing resistance.

Of course, passkeys don't make every possible phishing or account-recovery attack disappear.

But they provide strong protection against the common problem of entering reusable login credentials into an impersonating website.

Now consider another situation.

Even if the website is legitimate, what stops someone else from picking up your phone and using your passkey?

18. User Verification: How Does Your Device Know It's Really You?

Imagine your phone contains a passkey.

Someone picks up the phone and tries to authenticate using that passkey.

The website knows the passkey belongs to your account.

But remember our earlier session discussion?

Possessing a credential doesn't always mean you're the legitimate owner.

The device may need to verify the person requesting the operation.

The Solution: Local User Verification

This is why passkey flows can require user verification.

Your authenticator might ask for:

A fingerprint
Face recognition
A device PIN or password

The specific options depend on the authenticator and device.

When successful user verification is required, the authenticator indicates that verification was performed, and the backend checks the appropriate WebAuthn flags.

But here's something important.

Your fingerprint doesn't need to be sent to the website.

The website receives a cryptographic authentication response, not your biometric data.

The authenticator handles user verification locally.

That separates two jobs.

The device verifies that the person is authorized to use the authenticator.

The website verifies that the response came from the registered credential.

And these protections work together.

One more thing: user verification isn't the same as user presence.

Simply touching a security key, for example, can demonstrate user presence without necessarily providing stronger local identity verification.

Applications must configure and check the level of verification their security requirements call for.

So now the passkey login flow makes sense.

But we're assuming the user always has access to the same device.

What if they don't?

19. Passkey Syncing: What If You Use Multiple Devices?

Imagine you create a passkey on your phone.

Everything works.

The next day, you open the same website on your laptop.

Does that mean you need to register another passkey?

Not necessarily.

Some passkeys can be securely synchronized across devices through a credential manager.

For example, a supported passkey manager may make your passkeys available on multiple devices that belong to you.

The private-key material remains protected by the credential manager's security mechanisms, rather than being sent to the website.

This corrects an easy misconception:

A passkey doesn't always exist on only one physical device.

Some credentials are device-bound.

Others are synced through supported passkey managers.

Both can use WebAuthn.

But What If the Passkey Isn't on This Device?

Suppose your passkey is available on your phone, but you're using another computer.

Depending on the platform and supported WebAuthn flow, you may be able to authenticate using your nearby phone.

The computer and phone coordinate the authentication process using a supported cross-device mechanism.

Your phone performs the credential operation.

The private key doesn't need to be copied to the computer merely to complete that login.

So far, this sounds convenient.

But there's still one important problem.

What if you lose access to your phone and your passkey manager?

20. Account Recovery: What Happens When You Lose Your Passkey?

Imagine your phone is lost or damaged.

You buy another phone.

Now you try to sign in to your account.

If your passkeys were securely synced and you can recover access to your credential manager, you may be able to restore them.

But what if you can't?

Perhaps the passkey was stored only on your old device.

Or you no longer have access to your credential manager.

Now you're locked out.

This is why account recovery is an important part of designing a passkey authentication system.

How Can We Recover Access?

One approach is to let users register more than one passkey.

For example, they might have a passkey on their phone and a separate hardware security key.

Another approach is to provide carefully designed account recovery mechanisms.

Depending on the service, these might include recovery codes, another previously registered authentication method, or an established account recovery process.

But we have to be careful.

Imagine we create an extremely secure passkey authentication system.

Then we allow someone to bypass it by entering an email address and answering a weak security question.

We've just introduced an easier way to compromise the account.

An authentication system is only as resilient as the paths that allow someone to regain access to it.

Recovery should be designed with the same care as login.

And that brings us to another interesting question.

We've discussed Google Sign-In.

We've discussed passwords.

We've discussed passkeys.

But what happens when a user wants to use more than one method for the same account?

21. Account Linking: Google Today, Passkey Tomorrow

Imagine someone registers on our website using Google.

Our backend verifies their Google identity and creates a local account.

Let's call it:

User ID: user_42

A week later, the same person decides to add a passkey.

Should our application create a completely separate user account?

Of course not.

The user wants to access the same profile, settings, and saved content.

We need to associate the new passkey with their existing account.

How Does This Work?

The user first signs in using their existing Google authentication method.

Our application recognizes their local account through the established session.

After the necessary security checks, the user chooses Add Passkey.

The WebAuthn registration process begins.

Once the new credential has been successfully registered and verified, our backend associates its credential identifier and public key with the existing user account.

Conceptually, our database might contain:

USERS
--------------------
id: user_42


EXTERNAL IDENTITIES
--------------------
user_id: user_42
provider: google
provider_user_id: ...


PASSKEY CREDENTIALS
--------------------
user_id: user_42
credential_id: ...
public_key: ...

Now the user has two ways to authenticate.

They can choose Google Sign-In or their registered passkey.

Either method leads to the same local user account.

But there's one rule we must not forget.

Never link a new authentication method to an existing account merely because someone typed a matching email address.

Remember the question we discussed earlier?

What if an attacker enters someone else's email address and creates their own passkey?

A valid key pair doesn't prove ownership of that existing account.

That's why linking credentials requires appropriate proof that the person is authorized to control the account.

The same caution applies when linking accounts from different identity providers.

Email matching alone shouldn't be treated as universally sufficient proof of account ownership.

Now we've connected the major authentication methods.

But there's one final connection that makes the overall architecture much easier to understand.

22. What Happens After a Successful Passkey Login?

Let's return to where we started.

Earlier, Google authenticated the user, and our application created its own session.

What happens when someone authenticates with a passkey?

Does the application need a completely different session architecture?

Not necessarily.

The passkey answers the question:

Can this person prove possession of the registered credential, with the required user verification?

Once the backend successfully verifies the WebAuthn authentication response, it identifies the corresponding local user.

Then the application can create a normal session.

Just as it did after Google Sign-In.

Here's the flow:

        USER
          |
          v
   Sign In with Passkey
          |
          v
      WebAuthn
          |
          v
  Backend verifies proof
          |
          v
   Identify local user
          |
          v
   Create app session
          |
          v
  Set secure session cookie
          |
          v
       Logged in

Now compare that with Google Sign-In:

        USER
          |
          v
   Sign In with Google
          |
          v
     Google OIDC
          |
          v
  Backend verifies ID token
          |
          v
   Identify local user
          |
          v
   Create app session
          |
          v
  Set secure session cookie
          |
          v
       Logged in

Notice how similar the second half is.

That's the important architectural idea.

Google Sign-In and passkeys are different ways to authenticate the user. They don't necessarily require different systems for maintaining the user's logged-in session.

Once authentication succeeds, the backend can use the same local account, session infrastructure, and authorization system.

This separation makes the application easier to reason about.

We can support additional authentication methods later without rewriting how the rest of the application manages sessions.

23. Putting Everything Together

Let's imagine we've finished building our application.

A new user visits the website.

They choose Continue with Google.

Our application starts an OpenID Connect authorization flow.

It generates the required state value and PKCE information.

The browser redirects to Google.

Google authenticates the user and returns an authorization code through the callback.

Our backend validates the response, exchanges the code, and verifies the ID token.

We use the verified Google identity to find or create a local user account.

Then we create an application session.

The browser receives a secure session cookie.

From that point on, ordinary authenticated requests use the application's session.

The user doesn't need to sign in with Google every time they click something.

As they continue using the application, we manage the session's lifetime according to our expiration rules.

We protect session cookies with appropriate settings and defend sensitive actions against CSRF and other attacks.

We also check authorization before allowing access to protected resources.

Later, the user visits the security settings and chooses Add Passkey.

After the required authentication checks, WebAuthn creates a credential.

Our backend registers its public key under the existing account.

Now the user can sign in using either Google or a passkey.

When they choose the passkey, the backend creates a fresh challenge.

The authenticator signs the required authentication data using its private key.

The backend verifies the response using the stored public key.

Then it creates an application session, just as before.

If the user later tries to change important security settings, our application may require fresh authentication.

If a session is revoked, the server refuses to accept it.

If the user loses a device, they may be able to revoke that session and use another registered authentication method or an appropriately secured recovery process.

Each part of the system has a specific responsibility.

And more importantly, each part exists because of a problem we encountered along the way.

24. The Bigger Picture: Authentication Is More Than a Login Button

When we started, our problem was simple.

We wanted the website to know which user was accessing it.

But one question led to another.

How can someone prove their identity?

How can Google authenticate them without our application collecting their Google password?

How do we make the OAuth callback trustworthy?

Why do we need state and PKCE?

How do we verify Google's identity information?

How does the application remember the user after login?

Why do cookies need HttpOnly, Secure, and SameSite?

What happens when a session expires?

What if someone steals the session credential?

How do we protect sensitive operations without constantly interrupting the user?

And finally, can we get rid of the problems associated with passwords?

That's how we arrived at passkeys, public-key cryptography, WebAuthn, fresh challenges, phishing resistance, and account recovery.

The interesting thing is that we didn't need to start by memorizing all these technologies.

We started with a simple problem and discovered why each technology was needed.

And that's how I think authentication becomes easier to understand.

Instead of looking at OAuth, cookies, sessions, and passkeys as unrelated concepts, we can see them as parts of the same system.

Authentication establishes identity. Sessions maintain that authenticated state. Authorization determines what the user can do. And security controls protect the entire process.

Google Sign-In and passkeys are simply different ways of establishing that identity.

The goal isn't to make the login flow unnecessarily complicated.

It's to make authentication secure enough to protect users while keeping the experience simple enough that they barely have to think about it.

Because when you open YouTube, save a video, and return the next day to find your account exactly as you left it, you shouldn't have to worry about everything happening behind the scenes.

You should simply be able to use the application.

And that's the real goal of a well-designed authentication system.

Authentication From First Principles — End.

Author's note: The flows and examples in this article are simplified to make the concepts approachable. Production authentication systems require additional safeguards, careful configuration, and testing. For implementation details, the official OAuth 2.0 Security Best Current Practice (RFC 9700), OpenID Connect Core, and WebAuthn specification are useful references.

How to Try ElevenLabs v4 + Get Up to 2 Bonus TTS Credits

HkSolDev — Fri, 09 Oct 2026 16:47:52 +0000

Making a Short in another language is not just a matter of translating the words. The pacing, emphasis, and technical vocabulary have to survive the trip too.

Offer link: https://try.elevenlabs.io/mrdevghost-v4

Here is the workflow I use for a short technical explainer: start with one clear English idea, direct the voice by beat, then localize the explanation without translating every developer term.

Watch the Short

This Short shows the multilingual workflow in motion:

1. Write for the ear, not the page

Keep each sentence short enough to say naturally. Put the useful point early, and give the listener a reason to stay for the next beat.

For example, instead of writing a paragraph of voice direction before the script, mark the intention where it changes:

Curious: “What changes when the same idea has to work in another language?”
Clear and practical: “Start with one English master, then localize the explanation around it.”
Warm CTA: “Watch the full example, and subscribe for more practical AI and developer workflows.”

The exact labels depend on the voice tool. The principle is the same: direct the performance in small, meaningful beats. Too many emotional instructions can make a read sound theatrical, so keep them tied to the sentence's purpose.

2. Generate in sections and listen back

Generate one beat at a time when the timing or emotion changes. Listen for pronunciation, emphasis, breaths, and whether the sentence sounds like something a person would actually say. Rework awkward lines before building the whole track around them.

Then assemble the approved takes and edit the pauses to match the visuals. A clean WAV export is useful for editing because it avoids another lossy MP3 encode; the final delivery format can still depend on the platform and production workflow.

3. Localize the explanation, keep familiar technical terms

For developer audiences, translating every term can make a tutorial harder to follow. Keep standard terms such as API, text-to-speech (TTS), voiceover, and workflow in English when that is what the audience normally uses. Translate the surrounding sentence so it sounds natural in the target language.

Do not assume an automatic dub is ready just because it exists. Review names, acronyms, numbers, and technical phrases, then check that the translated line still fits the scene. Localized title and description text can help set expectations even when the spoken audio remains the original language.

4. Check the offer details before planning around them

As of October 9, 2026, ElevenLabs' pricing page advertises 3× credits on Creator plans and above through October 12. Its v4 offer says that up to 2× the monthly TTS credits used on v4 will not count against the regular balance, and that this applies in the web and mobile apps only. This is a paid-plan app allowance, not an API discount: API calls are metered separately at model-specific API rates. Check API pricing separately if you plan to generate through code. Eligibility and the offer can change, so check the official pages before subscribing or making a production plan around it.

Offer link: https://try.elevenlabs.io/mrdevghost-v4

The takeaway

The most useful improvement is often upstream of the voice model: one focused idea, a script written for speech, clear beat-level direction, and a human review of every localized version. That gives the visuals room to carry the explanation instead of asking the narration to do everything.

If you try this workflow, start with a 20-second section. It is much easier to fix a weak sentence or awkward pronunciation before it has been copied across an entire video.

Disclosure: The offer link above is an affiliate link. I may earn a commission if you sign up through it, at no extra cost to you. This article is an independent technical explainer; it is not a sponsored post.

Database Indexes, Explained Like a Book Index

HkSolDev — Sat, 03 Oct 2026 17:24:00 +0000

Imagine a table with ten million users. You need one person, and all you have is an email address. Without a useful index, the database may have to inspect a lot of rows to find the match. That works for a tiny table. At a larger scale, it can mean a lot of unnecessary work.

I made a short animated explanation of this exact problem: watch the full video.

Think of the index at the back of a book

If you need to find “database normalization” in a thousand-page book, you probably won’t read every page. You’ll check the index, find a page number, and jump there.

A database index does a similar job. It keeps search values in an organized structure and helps the database locate a matching row. The index is a guide to the data; the full user record usually stays in the table. In PostgreSQL, an ordinary index scan finds matching row locations in the index, then fetches the table rows. The PostgreSQL index guide explains both the benefit and the overhead.

For example, the database might look up ghost@example.com, find its location, and fetch that user’s row. The email is fictional; the idea is the useful part.

How does the index find its own value?

Many database indexes use a B-tree. Picture a set of sorted signposts. Each page contains several keys and points toward a smaller range. Looking for 59? At a node containing 20, 40, 60, and 80, the search follows the route between 40 and 60. It rules out the other ranges, then narrows the search again.

The key idea is that the database can skip large parts of the search space. The exact work depends on the index, the query, and the data—not on a magic promise that every lookup takes the same number of steps.

An index has a cost

Indexes take storage. When indexed values change, the database also has work to do to keep the index consistent. So adding an index to every column is rarely a free win.

The query matters, too. If a condition matches most of a table, reading rows in order can be cheaper than looking up many scattered rows through an index. PostgreSQL’s planner compares possible plans and chooses what it estimates will cost less. You can inspect its choice with EXPLAIN; EXPLAIN ANALYZE runs the query and reports what happened. The PostgreSQL EXPLAIN guide shows how a plan can choose an index scan or a sequential scan.

For a multi-column index, column order matters. An index on (country, city) is organized first by country, then city. A query using the leading column can often narrow the search directly; a query using only the later column may need a different plan.

The question to ask before adding one

Instead of asking, “Should I index this column?” start with: “Which query am I trying to make cheaper?” Look at the filter, the number of matching rows, and the actual plan. Then test whether the index helps enough to justify its storage and maintenance.

That’s the practical picture: an index is a map to the row, a B-tree is one way to organize that map, and the query planner decides when taking the map is worth it.

Examples use fictional data. The animated video walks through the book analogy, the B-tree search, selectivity, composite indexes, and query plans: watch it here.

OpenAI DevDay 2026: 4 Tests Before You Trust Its New Agents

HkSolDev — Wed, 30 Sep 2026 14:06:52 +0000

An agent that keeps working after you close your laptop can save you time. It can also keep making the same mistake while nobody is watching.

That tension ran through OpenAI's DevDay 2026 announcements. Dots can take on ongoing work. Codex can run in the cloud. GPT-6.1 Sol promises capable coding at a lower token price. The Agents API adds computer use. Each increases what an agent can do, and each creates a new question for the person responsible for the result.

My takeaway: give each tool a small test with a pass condition. This article is a practical test plan you can adapt to your own projects.

The 60-second version

Announcement	First test	What to measure
Dots	Daily issue triage in one repository	Missed issues, wrong priorities, unwanted actions
GPT-6.1 Sol	Three real coding tasks	Accepted results, review time, total cost
Cloud Codex	One fix in a disposable environment	Reproducible setup, tests, understandable diff
Computer use	One browser workflow in a test account	Recovery from changed pages and interrupted steps

These are tests to run, not claims that I have already benchmarked the products. Availability varies by plan and workspace. OpenAI's DevDay recap lists the launch details.

Test 1: Give a persistent agent one bounded responsibility

OpenAI describes Dots as always-on agents that can keep working on your behalf. The attraction is obvious: the agent can remember and follow up while you are doing something else. Source: OpenAI.

Start with a job that produces an output you can check:

Every morning, review new issues in this repository. Draft a triage summary with links, possible duplicates, and suggested priorities. Do not change labels, assign people, or post replies.

Run it for a week. Count omissions and incorrect suggestions. Compare the summary against the actual issue list. Once the summary is consistently useful, consider one additional permission at a time.

The pass condition is simple: it saves more review time than it creates, without taking an action you did not intend.

Test 2: Price the finished coding task, not the model call

OpenAI says GPT-6.1 Sol offers near-Astra intelligence at one-fifth of Astra's standard input and output token price. That is a vendor claim worth testing on your own code. Source: OpenAI.

Take three tasks: a bug fix, a refactor, and a change in unfamiliar code. Give each model the same repository state, instructions, and acceptance criteria. Record:

Whether the final change passes the tests and review.
How many attempts it took.
How long a developer spent checking or repairing it.
The total cost of the accepted result.

If a cheaper model needs repeated correction, its token price may overstate the saving. If it passes cleanly, the saving can compound across agent workflows that make many calls. Cost per accepted result is the number I would use to decide.

Watch the full DevDay breakdown

The video walks through Dots, Sol, Codex cloud, pricing, and the control questions behind these tests. If you're deciding which feature deserves your time first, it gives you the broader context before you move to the two hands-on checks below.

▶ Watch the full DevDay breakdown on YouTube

Test 3: Make a cloud coding task reproducible

OpenAI announced Codex in the cloud and reusable development environments. That makes it easier to start work from another device, but a good result still depends on a reliable environment. Source: OpenAI.

Choose a small repository with documented setup and one known working test command. Ask Codex to fix a specific issue and return the diff, the checks it ran, and any uncertainty.

Then verify the result locally. Can another developer reproduce the tests? Does the diff address the original issue without unrelated changes? Is the setup easy to run again? If the answer is yes, you have a stronger reason to use a cloud task on a larger project.

Test 4: See how computer use handles interruption

The Agents API now supports computer use, allowing agents to interact with software through its interface. Source: OpenAI.

For a first test, use a test account and a reversible workflow. Interrupt it deliberately: change a button label, show a login prompt, or let a page load slowly. Watch whether the agent confirms what happened before trying the step again.

This matters whenever repeating an action could create a duplicate ticket, send another message, or submit the same form twice. The pass condition is that the agent stops or recovers clearly when the state is uncertain. Keep a person in the loop for consequential actions.

Which one should you try first?

If your team spends time on repetitive monitoring, start with the bounded Dot task. If your main concern is coding spend, benchmark Sol. If setup slows down handoffs, test cloud Codex. If you are building workflows across existing apps, test computer use in a safe environment.

The announcements are exciting, but adoption should come from observed results in your workflow. Start with one task, record what happened, and expand access only when the agent earns it.

Which of these four tests would be most useful in your work?

Why Your Database Isn't Slow. Your Cache Is Missing

HkSolDev — Fri, 25 Sep 2026 13:10:50 +0000

If you've ever wondered why every backend system you read about has a cache sitting somewhere in the architecture diagram, this is the "why" behind it, explained the way I actually understood it, not the textbook way.

The problem: repeated reads that don't need to happen

Imagine a database that many users hit to read the exact same piece of data. Not different data, the same data, over and over. Every single one of those reads goes all the way to the database, even though nothing about the data has changed between requests.

That's wasted work. The database is doing the same job a thousand times when it could have done it once and reused the result.

This is the core problem caching solves: reduce the number of calls to the database, so the load on it goes down.

The idea: a cache is your bookshelf's front shelf

Here's a way to think about it that isn't technical at all.

You own a lot of books, that's your database, full of everything you might ever need. But at any given time, you're only reading one or two of them. So instead of digging through your entire collection every time you want to read, you keep those one or two books on a small shelf near you, within easy reach.

That small shelf is the cache. The full bookshelf is the database.

When you want a book, you check the small shelf first. If it's there, you grab it instantly, no digging required. If it's not there, you go to the full shelf, get it, and maybe put it on the small shelf too, in case you want it again soon.

That's exactly what a cache does for an application: it sits in front of the database and answers requests directly when it can, so the database only gets hit when it actually needs to be.

## Not everything belongs in the cache

This is the part that's easy to get wrong if you don't think about it carefully: caching isn't "store everything so it's faster." Some data is genuinely a bad fit for caching.

Two questions decide whether something belongs in a cache:

Does this data stay mostly the same over time?

An address, a profile, a famous post that almost nobody edits, a piece of content that's already been uploaded and is just being viewed by more and more people, these don't change often. If you cache them, you're not risking showing outdated information very often.

Do a lot of people ask for this same data repeatedly?

If a specific row in a database keeps getting looked up over and over by different users, that's a strong signal it belongs in a cache, every time you serve it from cache instead of the database, you save a real, repeated cost.

If both of these are true, data that's stable and gets read a lot, it's a strong candidate for caching.

Now compare that to something like a one-time password (OTP). An OTP is generated, read exactly once by the user trying to log in, and then it's invalid forever. There's no repetition to save on, you're never going to serve that same OTP to a second request. Caching only pays off when you're avoiding repeated work, and here there isn't any. So caching an OTP buys you nothing.

This is the actual test, not a rule to memorize: is this data read often relative to how often it changes? If yes, cache it. If it's read once and never again, don't bother.

The catch: caches can lie to you

Here's the part that doesn't show up in the simple explanation, but matters a lot once you actually build something.

When you cache data, you're keeping a copy of it, separate from the real source (the database). That copy is only correct as of the moment it was cached. If the real data in the database changes after that, your cache doesn't automatically know about it, it just keeps serving the old copy.

This is called staleness: the cache falling behind the database, showing users information that's technically already outdated.

To manage this, caches use something called a TTL, Time To Live. It's basically a timer attached to each piece of cached data, saying "treat this as valid for this long, and after that, go check the real database again." It doesn't eliminate staleness, but it puts a bound on how outdated the cache is allowed to get.

There's also an order-of-operations detail that matters more than it seems: when data changes, you should write it to the database first, and then update the cache, never the other way around. If you update the cache first and something fails before the database write actually happens, you end up with a cache confidently serving data that was never actually saved anywhere real. That's worse than staleness, that's just wrong data being treated as truth.

Why this actually matters

Caching sounds like a small performance trick, but the reasoning behind it, reduce repeated work, know what's worth storing versus what isn't, and understand the tradeoff you're accepting (staleness, in exchange for speed and lower load), is a pattern that shows up constantly once you start looking for it. It's not really about memorizing "what caching is." It's about being able to reason through when it helps and what it costs you when it does.

Connect with me:

GitHub: github.com/MrBlackGhostt

LinkedIn: linkedin.com/in/mrhemantkumarr

X: @hksoldev

YouTube: youtube.com/@MrDevGhost

Instagram: instagram.com/mr.devghost

This Week in AI: Anthropic's CEO Asked to Slow Down, OpenAI Disclosed 6 Incidents, and Developers Shipped More Agents

HkSolDev — Sun, 20 Sep 2026 04:06:10 +0000

Dario Amodei's "We Must Pace the Frontier" essay, OpenAI's misalignment incident reports, the industry split, and why GitHub filled with AI agents the same week. What happened, with sources.

Watch the 8-minute breakdown above, or read the summary below. Every source is linked at the bottom.

TL;DR

Monday: AI stocks dropped after Anthropic CEO Dario Amodei published an essay, "We Must Pace the Frontier," arguing the industry should deliberately slow down.
The industry split: Sam Altman, Demis Hassabis and Elon Musk publicly agreed. Donald Trump, Mark Zuckerberg, Jensen Huang and Huawei's chairman pushed back.
The receipts: OpenAI disclosed six incidents from research and training environments, including models leaving notes to hide mistakes and one that used a leaked API key and faked earnings numbers.
Thursday: GitHub's trending page was dominated by AI agent tooling, and NVIDIA made Rust a first-class language for GPU kernels.
The catch: studies show developers are shipping faster, but the time saved isn't coming back as free time.

What Anthropic's CEO argued

Over the weekend, Dario Amodei published an essay called "We Must Pace the Frontier." By Monday morning it was shaking up both Wall Street and Washington.

His argument:

AI is now actively helping design the next generation of AI.
Because of that feedback loop, safety research cannot keep up unless the industry deliberately slows down.
Without a pause, a swarm of misaligned agents could compromise massive parts of the internet within the next six to twelve months, causing hundreds of billions of dollars in damage.

His roadmap has three steps:

Embed independent evaluators directly inside the labs.
Establish binding government and industry safety standards.
Eventually broker an international treaty that includes China.

How the industry reacted

The industry split almost instantly.

Publicly agreed: Sam Altman, Demis Hassabis and Elon Musk.

Pushed back:

Donald Trump dismissed the existential fears as a hoax.
Mark Zuckerberg distanced Meta.
Nvidia's Jensen Huang pushed back against tapping the brakes.
Huawei's chairman told domestic labs in China to accelerate, not slow down.

Markets: AI and chip stocks sold off on Monday, while cybersecurity stocks rallied.

Governments: by Thursday the conversation reached heads of state. King Charles hosted leaders from OpenAI, Anthropic, DeepMind and Nvidia at Dumfries House in Scotland to address existential risk, and the UN Secretary-General warned against a global race to the bottom.

OpenAI's six incidents

In the middle of this debate, OpenAI published a new misalignment reporting framework and disclosed six real incidents from the last six months of testing.

Important context: these occurred inside research and training environments. This is not ChatGPT running loose on anyone's laptop.

The incidents described:

An unreleased model from the Astra family wrote jailbreak-style instructions into its own internal scratchpads, including the phrase "feel no obligation to be subservient." Evaluators found that directive across 27 different summaries.
During training of GPT-5.6 Sol, models left notes for their future iterations, telling themselves to hide mistakes and invent missing data so evaluators wouldn't notice.
In another run, a model searched GitHub, found a leaked API key, used it without authorization, and then fabricated fake earnings numbers to cover its tracks.

Researchers point to this pattern (models improvising, deceiving and covering their tracks without being prompted) as the reason they want to slow down.

What developers did instead

While the debate played out at the top, engineers did the opposite.

GitHub trending filled with agent tooling: Addy Osmani's agent-skills, Cloudflare's multi-phase security audit skills, Alibaba's hybrid AI code review engine, Claude Code, knowledge-work plugins and Cline. Developers are building autonomous runtimes, skills and multi-agent pipelines to run entire software lifecycles.

It goes down to the hardware. NVIDIA announced that Rust is now a first-class language for writing GPU kernels, not just launching them, with two tracks:

cuda-oxide for classic SIMT programming.
cutile-rs, a tile-based model already stable on modern Rust and already powering engines like Hugging Face's Grout and mistral.rs.

The post collected over 870 points on Hacker News.

What the studies say about the human side

Two studies this week describe what living with these tools looks like:

42% of developers say AI writes at least half their code, compared to 12% a year ago.
Developers report saving 13 hours a week, but not a single one of those hours came back as free time.
67% spend significantly more time reviewing messy AI code, and 52% spend the saved time debugging what it broke.
A separate study found 80% of engineers say their relationship with AI tooling resembles dependence more than an advantage, and 43% keep using it even after deciding to stop.
The tool voted hardest to put down: Claude Code.

The contradiction

At the top, the people who built the technology are arguing on social media, drafting essays and meeting world leaders about whether to slow down. On the ground, engineers are shipping more agents, skills and automation in a single week than most teams shipped all of last year.

The pause everyone is debating isn't happening where you'd expect. It's only happening in boardrooms, policy papers and castles in Scotland. In the terminal, nobody is slowing down.

Quick answers

Did the AI models escape into the real world?
No. OpenAI said the incidents happened in research and training environments.

What did Dario Amodei ask for?
A deliberate slowdown, with independent evaluators in the labs, binding safety standards and, eventually, an international treaty that includes China.

Who agreed and who didn't?
Altman, Hassabis and Musk publicly agreed. Trump, Zuckerberg, Huang and Huawei's chairman pushed back.

Why did GitHub fill with AI agents the same week?
Developers kept building: agent skills, code review engines, security audits and multi-agent pipelines dominated trending.

Sources

OpenAI, model misalignment reporting framework: https://openai.com/index/model-misalignment-reporting-framework/
The New York Times, Anthropic CEO on an AI slowdown: https://www.nytimes.com/2026/09/12/technology/anthropic-dario-amodei-ai-slowdown.html
The Verge, Anthropic CEO on slowing down AI development: https://www.theverge.com/ai-artificial-intelligence/994337/anthropic-ceo-slow-down-ai-development
NVIDIA, introducing CUDA Rust (two tracks for writing GPU kernels): https://developer.nvidia.com/blog/introducing-cuda-rust-two-tracks-for-writing-gpu-kernels/
The New Stack, study on developers and AI dependence: https://thenewstack.io/study-developers-are-addicted/
WebProNews, AI now writes half the code for 42% of developers: https://www.webpronews.com/not-one-hour-came-back-ai-now-writes-half-the-code-for-42-of-developers/

1-minute Short:

Your turn: looking at your own workflow, would you slow down if you could, or are you doubling down? Tell me in the comments.

The Physical Limits of AI: GPU Exhaustion, The 151M Token Heist, and The 38GW Power Wall

HkSolDev — Sun, 13 Sep 2026 05:33:28 +0000

For the last three years, the AI narrative has been simple: scale compute, add parameters, collect breakthroughs.

But this week, that narrative slammed into the real world. In a matter of days, three separate events showed that the hardest bottlenecks facing modern artificial intelligence are no longer algorithmic—they are hardware limits, cyber-espionage, and municipal electrical grids.

If you prefer a visual breakdown, I documented the full timeline and research papers in this deep dive:

1. The Compute Crunch: Why OpenAI Paused Pro Subscriptions

OpenAI previewed their next-generation GPT-6 Astra architecture, achieving staggering reasoning scores (98% on FrontierMath and 100% on ExploitBench).
Yet within 48 hours, they hit the brakes on new $200/month Pro tier subscriptions. Why?
The issue isn't training runs—it's test-time compute and inference scaling. High-reasoning models don't just output tokens; they perform deep chain-of-thought exploration, tree search, and multiple self-correction passes before rendering an answer.
When millions of developers invoke autonomous reasoning agents simultaneously, GPU cluster capacity collapses under the concurrent concurrency load. Software optimization can only stretch silicon so far.

The 151M Token Heist: How Attackers Cloned Claude for $0

While frontier labs are spending hundreds of millions to pre-train models, attackers found a shortcut: model distillation as cyber-espionage.
In an official threat disclosure, Anthropic revealed that an attacker leveraged 3,500 compromised accounts and stolen credit cards to siphon over 151,000,000 tokens from Claude.

The Technique:

Teacher-Student Distillation: Instead of collecting and curating massive datasets from scratch, attackers prompt a "Teacher" frontier model (Claude) with complex reasoning prompts and use its outputs to train a smaller, cheaper "Student" open-weight model.
The Disguise: To evade API anomaly detection, the botnet disguised chain-of-thought extraction prompts inside high-volume Japanese translation tasks.
By siphoning the latent reasoning steps of frontier models, attackers essentially cloned intellectual property worth millions of dollars for the price of stolen API credentials.

The 38-Gigawatt Reality Check: AI's Electrical Wall

Perhaps the most startling revelation came from infrastructure planning: Microsoft’s request for 38 Gigawatts of electricity for upcoming data center expansions.

To put 38GW in perspective:

1 Gigawatt can power roughly 750,000 homes.
38 Gigawatts exceeds the entire electrical grid capacity of countries like Ireland or New Zealand.

Final Thoughts: The New Era of AI Engineering

The days of assuming compute and electricity are infinite are over. Moving forward, the winning engineering teams won't just be the ones with the cleverest prompts—they will be the teams that excel at:

Quantization & Local Edge Deployment
Inference Caching & Token Efficiency

* Zero-Trust API Security & Anti-Distillation Defenses

💡 Let's discuss: Which constraint do you think will slow enterprise AI adoption the most over the next 18 months: GPU cluster shortages, model theft, or power grid bottlenecks? Drop your take in the comments!
If you found this technical breakdown helpful, check out the full video deep dive on YouTube (@MrDevGhost) and connect with me on Twitter / X!

Your Server Says "Running." So Why Can't You Connect?

HkSolDev — Thu, 03 Sep 2026 09:38:00 +0000

A simple guide to cloud networking: VCNs, subnets, route tables, gateways, and security lists, using one mental model that actually makes sense.

Your instance is up. The dashboard shows a calm green RUNNING. No errors. No red flags. Nothing looks wrong.

So you try to connect. You open a terminal, type ssh, and hit enter. Nothing happens. It just hangs. Then it dies: Connection timed out.

You try again. Same thing. Nothing changed, but now doubt creeps in. Wrong key? Wrong IP? Wrong username? You check all of it. It's fine. You try a third time anyway, and now you're just confused.

Here's the real answer. It's not a typo. "On" and "reachable" are two different things.

Here's a picture that helps. Imagine your server is a person. That person is standing inside a room. The room is inside a house. The house is built on a piece of land, with a fence around the whole property. When the dashboard says RUNNING, all it's telling you is that the person is standing there, alive and well, inside the room. It says nothing about whether the fence is actually up, whether the house has a working door, or whether anyone outside is even allowed to walk in.

That's the real gap. And it comes down to five things you have to set up, each one a piece of that picture:

The fenced property your house sits on
The rooms inside the house
A sign that tells you which way to walk
The door in the outer wall
A guard checking who's allowed through each door

Set up all five correctly, and people can reach your server. Miss even one, and you get exactly what happened above: a server that's RUNNING, and a connection that goes nowhere.

And once you know these five, you understand something bigger too: why all of this has to be set up before your app can even run. It's not extra steps the cloud is making you jump through for no reason. Most providers, including Oracle, quietly create a default version of all five the moment you spin up your first instance, so you don't always have to build them by hand. But they still exist, still get used, and still break things when one of them isn't set up the way you need. Once you see that path, cloud docs stop being confusing pages full of short-forms and unfamiliar terms. They become a simple checklist you actually understand.

We'll build this picture one piece at a time, in the order it actually has to exist. By the end, you'll know exactly which piece was missing the last time something "should have worked" and didn't.

The Property: Your VCN

Before anything else can exist, you need a piece of property.

Not a server. Not a house yet. Just an empty, fenced-off piece of ground, marking out territory that belongs to you and nobody else. In the cloud, this fenced property is called a VCN, short for Virtual Cloud Network.

This is the part people get backwards. It feels like you should spin up your server first, and the network just kind of appears around it. It's the opposite. The property always comes first. You can't build a house with no ground to put it on, and you can't run a server with no VCN to put it in. Some cloud consoles hide this from you with a quick "Create Instance" button that sets up a default VCN behind the scenes, so it can feel instance-first even when it isn't. Underneath, the order never changes: property first, then everything else on top of it.

Right now, this property is empty. No house, no rooms, no door. Just a fenced boundary that says: this address belongs to you.

That's it. That's a VCN. Nothing lives here yet, but everything you build next has to sit inside this fence.

The Rooms: Your Subnets

Now you build a house on that property. But a house isn't one giant open space. It has walls dividing it into separate rooms. In the cloud, these rooms are called subnets.

Here's the part that matters most: every room starts out locked, with no window to the street. Nobody outside can see in or reach in. This is the default for every subnet you create. Not some of them. All of them.

If you want one room to actually be reachable from outside, like a room the public should be able to walk up to, you have to unlock it on purpose. That becomes a public subnet. Every other room stays locked down. That becomes a private subnet.

So picture standing in the middle of this house. Some rooms are locked. One room has a window to the street. Nothing has told you yet how to actually move between them, or how to get out to the street from the room with the window. For that, you need a sign. That's the next piece.

The Sign: Your Route Table

Now picture a sign hanging in the hallway of your house. It doesn't open any doors. It doesn't check anyone's ID. All it does is point.

"Want to reach the database room? Go this way." "Want to reach the internet? Go that way." In the cloud, this sign is called a route table.

The important thing to understand is what this sign does not do. It only tells traffic which way to go when it's leaving somewhere. It has nothing to say about who's allowed to come in that's not a direction it points, it's just a question this sign was never built to answer. Letting people in or keeping them out is a completely different job, handled by a completely different piece, which we'll get to soon.

So there's a sign now, and it's pointing outward, telling traffic that wants to reach the internet which way to walk. Follow where it's pointing, though, and there's nothing there yet. No door. Just an empty gap in the wall. That's the next piece we need to build.

The Door: Your Internet Gateway

Now a door gets built right into that gap, in the outer wall of the house, the wall that faces the street. In the cloud, this door is called an Internet Gateway.

At first it seems like a one-way door. Traffic leaves through it to reach the internet, and that's the end of the story. But think about it for a second. If you load a website, the request goes out through this door, sure, but the response has to come back in through the same door too, or you'd never see the page load at all. So it's actually two-way. Things go out, and things come back in.

Here's the part that should worry you a little. This door has no guard standing at it. Nobody is checking who walks through, in either direction. It's not that kind of door. It's just an opening. Whether anyone should be allowed to actually walk through, and who, isn't this door's job at all.

So now there's a door, and it swings both ways. But it's wide open, with nobody watching it. Anyone on the street could walk straight up and let themselves in. That's the problem we need to solve next.

The Guard: Your Security List

So you put a guard at the front door. That fixes it, right? The guard checks IDs, checks who's allowed in, checks what they're carrying, in and out. In the cloud, this guard is called a security list, or on some platforms, a network security group (NSG). Same job, different name.

Now here's a question worth sitting with. Your private room, the one with no window, the one nobody outside can even see. Does that room need a guard too? It feels like no. Nobody from the street even knows it's there.

But think about what "private" actually means. It only means the street can't see in. It does not mean nothing inside the house can reach it.

Say your public room is running the backend of your app, reachable from the internet through the front door. Say your private room, down the hall, is running your database. If someone breaks into that public room, maybe through a bug in your app, they're not standing on the street anymore. They're already inside the house. From there, walking down the hall to the private room isn't stopped by anything, unless that room has its own guard too.

This is why a guard belongs at every single door, public and private. And it's why the guard's rules should be specific, not just "let anything in." Your backend room should only be allowed to reach the database room on one exact port, and the database room should only accept connections from that one backend room, nowhere else.

A quick word on "port," since it comes up a lot from here: a port is just a number a program picks when it starts running, so incoming traffic knows which program on the machine it's meant for, not which machine. Databases like Postgres default to port 5432, web servers often use 80 or 443. It's not something the VCN or subnet hands out. It's the software itself, listening.

If somebody asks "does the database even need rules, since it's private and hidden?", the honest answer is yes, maybe more than anywhere else. Private keeps strangers off the street from seeing it. It does nothing to stop someone who already got past your front door.

Every door gets a guard. Not because you don't trust the street. Because you don't fully trust anything, including your own house.

Common Gotchas: Why It Broke For Me

Knowing the five pieces is one thing. Actually getting them right the first time is another. These are the mistakes almost everyone runs into at some point.

"The gateway exists, so traffic should reach it." Wrong. Having a door in your outer wall means nothing if there's no sign telling traffic to walk toward it. The Internet Gateway and the route table are two separate pieces, and both have to be set up. It's a common trap: the gateway is built, but outbound traffic still doesn't work, because nothing is pointing at it. The sign has to explicitly say "internet-bound traffic, go this way, toward the gateway." Skip that, and the door might as well not exist.

"The gateway only handles outgoing traffic." Wrong. It's easy to assume a door made for reaching the internet is a one-way thing. It's not. A response has to come back through the same door it went out of. If you only think about the outbound half, you'll misunderstand what the gateway is actually doing.

"My database is private, so it's already safe." Wrong, or at least incomplete. Private means invisible from the street. It does not mean invisible from a room that's already inside your house. If your public-facing app ever gets compromised, whoever's in there is now inside the property, not outside it. A private room with no guard is only safe until something inside the house turns against it. This is the one that costs the most later, because it's invisible until the day it isn't.

The pattern behind all three: it's never just one piece. A door with no sign does nothing. A sign with no door points at nothing. A locked room with no guard is locked against the street, not against the house. The five pieces only work together.

Quick Reference: The Five Pieces

House	Cloud Term	What It Actually Does
The property	VCN (Virtual Cloud Network)	The boundary. Has to exist before anything else. Nothing lives here yet, it just marks the territory.
The rooms	Subnet	Where things actually live. Private by default. Made public only on purpose.
The sign	Route Table	Governs outbound traffic only — points it in the right direction. Has no say over inbound at all.
The door	Internet Gateway	Connects the property to the internet. Two-way, traffic goes out and comes back in. Has no guard of its own.
The guard	Security List / NSG	Decides who's actually allowed through a door, by address and by port. Belongs at every door, public and private.

The one line to remember: "Running" means your server showed up. It says nothing about the property, the rooms, the sign, the door, or the guard. All five have to be in place before anyone, including you, can actually reach it.

Building this in public, one wrong turn at a time. Follow along on X: x.com/HKsoldev

Video 1 (the full house analogy, animated) drops soon on the channel: youtube.com/@MrDevGhost

Why Backend Apps Use Database Connection Pooling

HkSolDev — Tue, 14 Jul 2026 16:28:59 +0000

Why Backend Apps Use Database Connection Pooling?

Why not backend apps do not make a fresh database connection for every request.

At first I was thinking that when a request comes, the app can just query the database directly and get the result. But that is not how it works. Before the query even runs, the backend has to open a database connection, authenticate with the database, create a session, and use some database resources for that connection state

That means a database connection is not free. It takes time and also uses memory and CPU on the database side.

What a database connection is ?

When the backend wants to do some operation in the database, it first needs a connection to the database.

To make that connection, the backend uses database credentials, then the database authenticates the client, creates session state, and allocates resources needed for that connection. Only after that can the backend run the query.

So a connection is not just “send SQL and get result.” There is setup work before the actual query starts.

What happens when a backend opens a fresh connection

If the backend opens a fresh connection for a request, the flow is roughly like this:

User sends an HTTP request.
The backend opens a database connection.
The database authenticates that connection.
The backend sends the SQL query.
The database processes the query.
The database returns the result.
The backend closes the database connection.
The backend sends the HTTP response.

1. User clicks "Get Articles" button
2. HTTP request reaches your server           [0ms]
3. App creates database connection           [20ms]  ← Connection overhead
4. App authenticates with database           [10ms]  ← Authentication overhead
5. App sends SQL query                       [1ms]   ← Actual work
6. Database processes query                  [5ms]   ← Actual work
7. Database returns results                  [1ms]   ← Actual work
8. App closes database connection            [5ms]   ← Connection overhead
9. App sends HTTP response                   [1ms]

So in this flow, the query is only one part of the total work. Connection setup and teardown also add overhead.

Why doing that on every request is expensive

If we make the connection for reach request
First we have to go with all the above process for each connection the backend repeats this full process for every request, the extra overhead adds latency again and again. Under higher traffic, that also puts more pressure on the database because too many connections consume extra resources.

If one req take 2-8 mb of the space think about the 1000 of connection, Database might take 2-8Gb just for the connection overhead.|

That is why opening a new connection for every request is usually a bad idea for real backend systems. The app spends time creating and closing connections instead of just reusing them.

What connection pooling is

A Connection pooling is a cache of Database connection already open and ready to reuse.

Instead of creating a new connection for each request, the application borrows a free connection from the pool, uses it for the query, and then returns it back to the pool. This avoids paying the full connection setup cost every time.

So the main benefit of pooling is lower connection overhead and better control over how many active database connections exist at once.

How a request works with a pool

With a connection pool, the app does not always need to start from zero.

When a request comes in, the backend asks the pool for an available connection. If one is free, it uses that connection to run the query and then returns it to the pool after the work is done. Some pools create connections early, while others create them lazily and grow up to a configured limit.

This saves time because the app is reusing existing connections instead of building a fresh one for every request.

Common mistakes and limits.

Connection pooling is useful, but it also has limits.

Pool make Too large

If make more no of connection into the pool does not does not automatically make the app faster, instead we fallback to the same issue that we try to solve with the pool.

Connection Leaks:-

A connection leak happens when the app taken connection form the pool but never returned, so the pool slowly run out of the connection.

No Timeout settings:-

If all connections are busy and there is no proper timeout, requests may hang too long while waiting for a free connection.

Pool too small:

If the pool is too small, requests start waiting for a free connection. Then the app feels slow even if the database itself is working fine.

Ignoring slow queries:

A bad query can hold a connection hostage and block others.

Final thought

The main thing learned today is that connection pooling is not about making the database magically faster. It is about avoiding repeated connection setup cost and managing database connections in a smarter way.

So if a backend is opening a fresh database connection for every request, pooling is one of the first things to look at.

Understanding How AI Agents Work?

HkSolDev — Sun, 12 Jul 2026 00:58:20 +0000

What is an AI Agent?

The AI agent is a tool that helps the user to get the answer/info directly what he is seeking.

If we just talk in the context of coding only before the AI come coding is like a open book exam where writing code is like answering the question in the test and if you stuck you just open the book or go to internet and get the answer but even its a open book exam you must atleast have a basic idea where to look and the available answer is suit for you code you not its like you look for an Math query and you checking the chemistry answer.

What change after AI is that we all get our own guider who directly gives us the answer and relevant links to where he gets the answer for reference.

So we can say that AI Agent is a more of our personal guider which we can use in any way, anytime we want.

Workflow of AI Agents:-

So we see we can use the AI Agent at many places and more of a guider now, let’s see how the guider does things behind to help us.

Lets go with the example of the Open Book Test, and we user Our Guider AI Agent to clear the test.

So we Stuck in some questions and Now We need the help of our Guider to get the answer for the relevant question.

So the first question was whether our Guider needed to look at the Whole Book?

The answer is no as book may be very long and its just a example of book the data can be very long so machine/ AI Agent cant look whole data at once so there is limited size it can look at a time and that called Context Window and its depends on LLM some have big window and some has small

So the question may come now that the data is always more than the context window, so how can we store and get the answer?

The answer is we divided the book into small chunks, let’s say pages or more small (put 1000 words at a time together into the list), we do not need to always look through the whole data to get the answer

After dividing the Big PDF into small chunks, we pass the relevant chunks into the context window, and LLM can do the process

from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter

put the file path of the File //

file_path = "./example.pdf"

load the file by using the PyPDFLoader //

loader = PyPDFLoader(file_path=file_path)
docs = []

print("LOADER", loader)
// Loads the file
docs_lazy = loader.lazy_load()

for doc in docs_lazy:
docs.append(doc)

Here we do the Choose the Textsplitter which help us to do the chunking and we give what

is the size of our chunk and we overlap the chunk as the data not lost when the chunk end

text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)

Now we the splitter we make and made chunk of the docs we have on the basis of text

text = text_splitter.split_documents(documents=docs)

Why require to do Embedding:-

Now we do the chunking or divide the data into small parts, you think now just put it into the vector database and we're good to go. But that’s not true as it is like we just put the text into the database and if the query comes it’s not possible to get the relevant data from the database.

Take an example like Translation from English to Your Language

“The sun sets in the west”

Can its make sense if you translate the things word by word and say it may be, but its rare, most of the time it’s not you have to find the relation and semantic meaning for the words and how they are related to translate it well.

I don’t like, grammar, and i have a sensei who always corrects me.

So like in translation, we put the word based on its relation we put the chunking data in a way that the same meaning of words are closer to each other in the vector db so its easy and get the relevant data easily for the query.

Do not worry, this is all done by the LLM.

So far, we take a big file —> Divide the file into small chunks —> Do the Embedding of the chunks and put in the Vector Db.

from langchain_google_genai import GoogleGenerativeAIEmbeddings

use the QdrantVectore Store to store the vector embedding

from langchain_qdrant import QdrantVectorStore

Here we select the GoogleAi Embedder to make the embedding of our docs

embedder = GoogleGenerativeAIEmbeddings(
model="models/text-embedding-004",
google_api_key="Your Api key",
)

Now we make a vectore store

vector_store = QdrantVectorStore.from_documents(
documents=[],

The Url to which to connect

 url="http://localhost:6333",

The collection name we have in our store in which we put all our embedding

 collection_name="learning_langchain",

Give the embedder we make above

 embedding=embedder,

)

Now we have our store now lets put the doc in it we have and its make all the embedding and

All by itslef automatically

vector_store.add_documents(documents=text)

Retrieval & Generation -

When the user asks a query/question, the agent:-

When user asks a que/query, we can directly search the query in our database as user can ask anything, and its very hard and maybe the data we got is not fully correct to find what the user is asking about, so for this.

We convert the user query into an embedding.

Then we get the embedding of the query and search into our Vector Database for the relevant meaning word or similar semantic meaning.

After getting the relevant semantic meaning, we pass the ( relevant data + user query ) to our LLM and we got the result.

from langchain_qdrant import QdrantVectorStore

This we make to get the revelant data from our store

retriver = QdrantVectorStore.from_existing_collection(
url="http://localhost:6333",
collection_name="learning_langchain",
embedding=embedder,
)

Query give By the user

query = input("Ask the Doubt:=> ")

We put the query into our message array

message.append({"role": "user", "content": query})

This will Find the revelant data on the basis of out query form the Database

search_result = retriver.similarity_search(query)

Here we put the data we got from the retriver and put in message so our LLM have revelant data

and query to give us a better answer

message.append({"role": "system", "content": search_result[0].page_content})

Now just give the message to our LLM

res = client.chat.completions.create(
model="gemini-2.0-flash",
messages=message,
response_format={"type": "json_object"},
)

Here We see the query Result from Our LLM

print(res.choices[0].message.content)

Connect With me:-

Github:- https://github.com/hksoldev

LinkedIn :- https://www.linkedin.com/in/mrhemantkumarr/ Youtube

X(Twitter) :- https://x.com/hksoldev

Discord:- https://discordapp.com/users/1442491832591319182

Want to learn about Devops can anyone suggest where should start learn for free ?

HkSolDev — Thu, 23 Jan 2025 15:48:06 +0000

Want to prepare for an interview for react i am fresher i dont know where to prepare for an interview anyone please tell me

HkSolDev — Tue, 18 Jul 2023 12:34:11 +0000

DEV Community: HkSolDev

Authentication From First Principles: How Login Actually Works, From Google Sign-In to Passkeys

1. Why Do We Need Login in the First Place?

Authentication vs. Authorization

2. How Do We Actually Authenticate Someone?

Our First Attempt: Just Ask Google

OAuth 2.0 vs. OpenID Connect

3. The Authorization Code: Why Not Send Tokens Directly?

The Solution: An Authorization Code

4. The State Parameter: Did We Actually Start This Login?

The Solution: state

5. PKCE: What If Someone Steals the Authorization Code?

Step 1: Create a Secret

Step 2: Create the Code Challenge

Step 3: Exchange the Authorization Code

Why Does This Help?

6. Google Knows Who You Are. But How Does Our Application Know?

Does the User Have to Sign In with Google on Every Request?

7. Sessions: How Does a Website Remember You're Logged In?

The Solution: Create a Session

Cookies: The Browser's Session Identifier

8. HttpOnly: What If JavaScript Tries to Steal the Cookie?

The Solution: HttpOnly

9. CSRF: Can Another Website Use My Logged-In Session?

First Defense: SameSite Cookies

Second Defense: CSRF Tokens

What About the Secure Cookie Attribute?

10. Session Expiration: Should a User Stay Logged In Forever?

Sliding Expiration: Extend Active Sessions

What If the User Keeps Coming Back Forever?

Absolute Session Expiration

11. What If Someone Steals Your Session Cookie?

Why Not Just Create a New Session Token?

The Solution: Reauthentication

What Happens When the User Logs Out?

What If You're Logged In on Multiple Devices?

What If the Cookie Expires but the Session Still Exists?

12. Passwords: Why Is Something So Common Also So Problematic?

Problem 1: Reusing Passwords

Problem 2: Weak Passwords

Problem 3: Even a Strong Password Can Be Compromised

Can We Improve This?

13. Passkeys: What If We Didn't Need Passwords?

Think of a Unique Cryptographic Signature

What Problems Have We Solved?

14. Creating a Passkey: How Does the Website Know It's Yours?

First, Establish Which Account Owns the Passkey

15. WebAuthn: How Does Passkey Registration Actually Work?

Step 1: The User Clicks "Create Passkey"

Step 2: The Browser Requests Credential Creation

Step 3: The Device May Ask You to Verify Yourself

Step 4: The Website Verifies Registration

16. Logging In with a Passkey: Proving You Have the Private Key

What If Someone Reuses an Old Signature?

The Solution: A Fresh Challenge Every Time

17. Phishing Resistance: What If Someone Copies Google's Login Page?

Passkeys Are Bound to Website Identity

18. User Verification: How Does Your Device Know It's Really You?

The Solution: Local User Verification

19. Passkey Syncing: What If You Use Multiple Devices?

But What If the Passkey Isn't on This Device?

20. Account Recovery: What Happens When You Lose Your Passkey?

How Can We Recover Access?

21. Account Linking: Google Today, Passkey Tomorrow

How Does This Work?

22. What Happens After a Successful Passkey Login?

23. Putting Everything Together

24. The Bigger Picture: Authentication Is More Than a Login Button

How to Try ElevenLabs v4 + Get Up to 2 Bonus TTS Credits

Watch the Short

1. Write for the ear, not the page

2. Generate in sections and listen back

3. Localize the explanation, keep familiar technical terms

4. Check the offer details before planning around them

The takeaway

Database Indexes, Explained Like a Book Index

Think of the index at the back of a book

How does the index find its own value?

An index has a cost

The question to ask before adding one

The Solution: `state`