feedScore =
  0.35 * freshness +
  0.30 * engagement +
  0.20 * relevance +
  0.10 * creatorFamiliarity +
  0.05 * karmaBoost

It looked right. I had my editor open and was about to start implementing it.

Then I asked myself where 0.35 came from. Not whether it looked balanced on the page, whether freshness deserved more weight than engagement. Where the actual number came from. I didn’t have an answer, because there wasn’t one to have.

Relevance is supposed to measure how similar a post is to content the user already engages with. That sentence assumes a user with an engagement history. My app has zero users. There’s no history to compare anything to, and there won’t be one on launch day either.

CreatorFamiliarity has the same hole in it. It tracks whether someone follows or regularly engages with a creator. On day one, nobody follows anybody. Every value in that column is zero for every user, and stays zero until people actually start using the thing.

KarmaBoost needs creators with accumulated karma. Nobody’s posted yet, so there’s no karma to accumulate.

Three of five signals in my formula can’t produce a real value on launch day. Not a weak value. No value.

My first thought was to patch around it: set relevance to some neutral constant, zero out creatorFamiliarity, let the math degrade gracefully. It would still run. You’d get a number out the other side. But a formula that returns a number isn’t the same as a formula that means something. If every new user gets an identical relevance score because I made the number up, I haven’t personalized anything. I’ve built a slow way to sort by date.

This is the cold start problem, and it shows up anywhere something ranks or recommends: feeds, search results, product suggestions, matchmaking. You need behavioral data to weight the model. Behavioral data only comes from people using the product. People only use the product if it already works reasonably well. And it only works well if the ranking is already good, which is the thing you were trying to build in the first place. You can’t validate feedScore against real engagement until real engagement exists, and it won’t exist behind a feed that’s ranking things arbitrarily.

I was trying to build the smart version of the system before the dumb version had produced a single data point worth being smart about.

So the fix isn’t a better formula. It’s accepting that the weighted version is a second phase, one that only becomes possible once a simpler system has been running long enough to generate the inputs it needs. The actual first version isn’t a formula at all — it’s a short list of rules that don’t need any history to evaluate: show posts from creators the user follows, then posts from creators they’ve engaged with before, then popular recent posts from the wider community, with a small freshness boost so new content doesn’t get buried under old popular stuff.

Every one of those can be answered for a brand-new user with zero training data. Who you follow is knowable the second you follow your first account. What’s popular right now is knowable from raw counts, no model required. There’s nothing to learn in any of it, just retrieval and sorting.

I’d been treating that rule-based version as the placeholder you ship while waiting to build the real thing. It’s not a placeholder. It’s the mechanism that produces the dataset the weighted formula will eventually need: which posts got liked, which got skipped, which creators people kept coming back to. Log that from day one, and by the time the follow-graph feed feels too rigid, the numbers to justify a smarter one already exist.

If a signal in your formula can’t produce a real value without prior user behavior, it doesn’t belong in the formula yet. It belongs in your logging.

A box on the left labeled “Client.” A box on the right labeled “Server.” An arrow going one way, another coming back. Simple enough.

But when I built the simulation for this concept, I realized the model is much weirder and more interesting than the diagram suggests. Because the diagram skips the part where everything breaks.

The world without it

Imagine you’re building a collaborative document editor. No server. Just users.

Every user stores their own copy of the document. When user A edits line 3, user B doesn’t know. When user B edits line 3 at the same time, you now have two different documents that both think they’re the real one.

You could try to sync them manually. Email files back and forth. Export, merge, re-import. But now you have versioning problems, merge conflicts, and a process that breaks down the moment a third person gets involved.

This is the world before the client-server model. Every user is an island.

What the model actually does

The client-server model introduces a single, shared source of truth.

Instead of everyone managing their own state, you centralize it. One server holds the real data. Clients ask for what they need. The server responds with what it has.

 Client → “Give me the document”

Server → “Here it is”

Client → “Save this edit”

Server → “Done. Here’s the updated version”

It sounds obvious. But the implication is enormous: now everyone is looking at the same thing. Collaboration becomes possible. Consistency becomes enforceable. You can build systems that scale.

The part the diagram lies about

Here’s what the clean diagram doesn’t show you:

The server can crash.

When I built the simulation, I added a “Kill server” button. One click, and every client stops receiving responses. Requests pile up in a queue. Latency climbs. The success rate drops to zero.

That’s the trade-off the model quietly introduces. When you centralize state, you also centralize failure.

Before the server existed, a single user going offline only affected that user. Now when the server goes offline, it takes everyone down with it. You’ve traded distributed chaos for centralized risk.

This is the thing interviewers are actually testing when they ask about the client-server model. Not whether you know what a request is. Whether you understand that centralization is a decision with consequences.

The thing engineers get wrong

Client does not mean frontend.

Server does not mean backend.

These are roles, not positions in a stack. A mobile app is a client. So is a microservice making a request to another microservice. Your backend can be a client to a third-party API. The labels describe behavior, not technology.

Once you internalize this, you start seeing the model everywhere:

- A browser loading a page → client-server

- A payment service calling Stripe → client-server

- A game syncing player state → client-server

- A chat app routing messages → client-server

The pattern is the same. The client initiates. The server responds. State lives centrally.

The interview version

If someone asks you about the client-server model, here’s what they want to hear:

1. Client initiates, server responds. The request-response cycle is the fundamental unit of communication.

2. Single source of truth. Centralized state enables consistency across multiple users.

3. Stateless vs stateful. A stateless server treats every request independently. A stateful server remembers previous interactions. Both are valid. The tradeoffs are different.

4. Horizontal scaling. When your server gets overwhelmed, you add more servers. Load balancers distribute the requests. This is why centralization doesn’t mean a single machine forever.

5. Single point of failure. The cost of centralization. Mitigated by replication, failover, and redundancy — but never fully eliminated.

Why this model matters in system design interviews

Every system design question starts here.

URL shortener? Client requests a short URL, server maps it to the original and redirects. Chat app? Clients send messages, server routes them and persists history. Payment system? Client initiates a transaction, server validates and executes it.

The client-server model isn’t just a concept you learn and move past. It’s the lens through which every distributed system is designed.

And the engineers who understand it deeply — the ones who see the failure modes, not just the happy path — are the ones who ask the right questions before writing a single line of code.

The simulation is live at https://hendrix-system-design-course.vercel.app/client-server-model . Crash the server. Watch what happens. That’s the part no diagram shows you.

I had created a fake user.

Not metaphorically. Literally.

It started with a strange symptom in my multiplayer Truth or Dare app. Two browsers would join the same room successfully. Both connected to WebSocket. Both emitted join_room. Both appeared in the UI.

But only one browser received room_update events.

The other sat there silently like nothing happened.

The logs looked almost identical:

[WS] Connected
Setting up socket listeners for room: 953b06
emitted join room

Step 1: I blamed React.

The console was flooded with terrifying-looking output from React’s development mode — doubleInvokeEffectsInDEV, cleanup calls firing twice, socket listeners mounting and unmounting repeatedly.

Classic Strict Mode behavior. I assumed my listeners were being detached before the server responded.

So I rewrote my socket subscriptions. Stabilized callbacks. Added guards around emit(). Moved listeners into refs. Eliminated stale closures.

Nothing changed.

Step 2: I blamed Zustand.

Maybe the listeners registry was getting recreated. Maybe reconnect logic was replacing the socket instance. Maybe isConnected was stale during emits.

I instrumented everything:

console.log("[WS] Connected")
console.log("Setting up socket listeners")
console.log("Cleaning up socket listeners")
console.log("Received room_update")

The frontend was fine. Events simply never arrived. That meant the bug was server-side.

Step 3: The clue I almost ignored.

A duplicate React key warning. I almost scrolled past it because the UI looked mostly correct.

That warning was the entire bug.

The actual problem.

When a room was created, I automatically inserted the host into the participants list as a placeholder:

host := &Client{
    UserID:   hostID,
    Username: hostUsername,
    Conn:     nil,  // ← no real socket
    MicOn:    true,
}
room.Participants = append(room.Participants, host)

Later, when the real WebSocket connection was established, a proper Client object was created — but my join logic checked whether the user was already in the room:

for _, p := range room.Participants {
    if p.UserID == client.UserID {
        alreadyIn = true
        break
    }
}

So the real, socket-connected client was rejected. The placeholder was already there.

The room now contained:

And my broadcast function silently skipped anyone with no connection:

if client == nil || client.Conn == nil {
    continue
}

That was it. The host browser never received events because the participant stored in the room had no WebSocket attached. I had accidentally separated "being in the room" from "having a socket."

The fix.

Stop creating placeholder participants. Let the real WebSocket client join normally.

I removed the pre-insertion entirely. Now:

1. Room starts empty

2. Host connects via WebSocket

3. Host emits join_room

4. Real connected client gets added to participants

5. Broadcasts work correctly

Both browsers immediately received room_update. The duplicate key warnings disappeared. Everything became stable.

The takeaway.

I was modeling “participants” as data instead of active connections. But in a real-time multiplayer system, those are not the same thing.

A user object without a live socket is not a connected participant.

And if two objects represent the same conceptual entity, your system will eventually drift into impossible states.

The duplicate React key warning ended up being the biggest clue in the entire debugging session.

Sometimes frontend warnings are really backend bugs wearing a disguise.

It started with a simple “invalid credentials” error. Every login attempt on my Truth or Dare app failed. The kind of bug that makes you question everything — your auth logic, your database, your understanding of cryptography.

Here’s how I debugged my way through it.

Step 1: Suspecting bcrypt

My first instinct was that bcrypt needed some kind of secret or salt to compare hashes correctly. It doesn’t. Bcrypt embeds a randomly generated salt *inside* the hash string itself — that long `$2a$12$...` value contains everything needed to re-hash and compare. No external secret required. Cross that off the list.

Step 2: Byte-level logging

I added raw byte logging on both the register and login paths in Go:

DEBUG register password bytes: [79 110 101]
DEBUG login password bytes: [79 110 101 49 49 49 49 49]

Different byte slices. Different passwords. I assumed I was mistyping during testing and moved on. I was wrong to dismiss this so quickly.

Step 3: The frontend

I dug into the Next.js login form and found something interesting — the password field was running format validation (uppercase letter, number required) *before* sending the request. That meant users who registered under looser rules could never log in. Fixed. Still broken.

I checked the axios instance, the request interceptors, the response parsers. Nothing was transforming the password. I logged the outgoing request directly from the browser:

password: “One11111” 

The frontend was sending the right value. So the bug was in the backend.

Step 4: The actual bug

My Go service function had this signature:

 func (s *Service) Register(

    ctx context.Context,

    username, email, fullName, password string,

) (uuid.UUID, error) 

And my handler was calling it like this:

 h.service.Register(

    ctx,

    req.Username,

    req.Email,

    req.Password,   // ← supposed to be fullName

    req.FullName,   // ← supposed to be password

)

I had swapped `fullName` and `password`. The app was hashing the user’s *display name* as their password on every registration. When they tried to log in with their actual password, it never matched.

One line. Hours of debugging.

The takeaway

Go (like many languages) uses positional arguments. When two parameters share the same type — in this case both are `string` — the compiler has no way to catch the swap. It silently does the wrong thing.

This is exactly the scenario where passing a struct instead of individual arguments shines:

 type RegisterParams struct {

    Username string

    Email    string

    FullName string

    Password string

}

With a struct, the field names make intent explicit. Order becomes irrelevant. The bug becomes impossible.

Next time you’re writing a function that takes more than two or three parameters of the same type — reach for a struct. Your future self will thank you.

Building a multiplayer Truth or Dare game in Go + Next.js. Writing about the bugs I hit along the way.

I’m Harrison, a software developer who spends a lot of time thinking about how technology works — and more importantly, how to explain it clearly to people who don’t eat stack traces for breakfast.

This newsletter is where I’ll share two things:

Tech concepts, explained properly. Not dumbed down, not buried in jargon. Whether you’re a hiring manager wondering what your engineers are actually building, a developer levelling up, or someone just starting out — I want every post to leave you feeling like you genuinely understand something new.

My own projects, behind the scenes. The decisions, the wrong turns, the “why did I do it this way” moments. Building in public, basically — with commentary.

I’m not here to be the loudest voice in tech. I just think good writing about software is rarer than it should be, and I want to contribute something worthwhile to that gap.

If that sounds like your kind of thing — welcome. I’m glad you’re here.

And if you have something you’ve always wanted to understand but never quite cracked — hit reply. That’s probably my next post

— Harrison.