Two-sided membership needs one lock, not two

Thu, 27 Aug 2026 00:00:00 +0000

Goroomlib models a relationship that points both ways: a Room holds a map of its users, and each User holds a list of the rooms it’s in. That redundancy is deliberate — both lookups need to be O(1) — but it’s also the whole bug surface.

The first version

AddUserToRoom did the obvious thing:

func (s *RoomService) AddUserToRoom(roomName string, user *User) {
    room := s.rooms[roomName]

    room.mu.Lock()
    room.users[user.ID] = user
    room.mu.Unlock()

    user.mu.Lock()
    user.joinedRooms = append(user.joinedRooms, roomName)
    user.mu.Unlock()
}

Each side is individually locked, so go vet and the race detector on a simple test are both happy. But there’s a window between the two critical sections where the room says “user is here” and the user says “I’m not in that room.” Anything that reads both — say, a disconnect handler that walks user.joinedRooms to remove the user from each — can run in that window and leak the membership.

Endpoint maps over hand-rolled methods

Tue, 25 Aug 2026 00:00:00 +0000

I’ve now written two client libraries for the same exchange API — one in Go , one in Java — and the thing I’d keep from both is the same: don’t write a method per endpoint. Describe the endpoints as data and dispatch through one function.

The shape of the problem

The API has roughly two dozen endpoints. They differ in four ways:

HTTP verb (GET, POST, DELETE)
path
whether the request must be signed
the response body

Everything else — building query params, adding a signature, choosing the verb handler, parsing the response — is identical. Writing a hand-rolled method per endpoint means writing that identical body 25 times, and then maintaining 25 copies of it when the signing scheme or the base URL handling changes.

Blog on Prateek Sharma

Two-sided membership needs one lock, not two

The first version

Endpoint maps over hand-rolled methods

The shape of the problem