N+1 in Code — Find the Bug¶

Category: Performance Anti-Patterns → N+1 in Code — per-item work in a loop that should have been done once.

This file is critical-reading practice. Each snippet is plausible real-world code in Go, Java, or Python. Read it the way a performance-minded reviewer does and answer:

Is there an N+1 here? Where is the per-item expensive work? How would you fix it — and how many calls would the fix make?

The catch: the expensive call is often not visible at the call site — it hides behind a getter, a lazy property, or a helper function. And one snippet is a trap: the per-item call looks like an N+1 but is actually correct — flagging it would be the mistake. Read slowly; count the round-trips; then open the answer.

How to use this file: decide your verdict and predict the call count before expanding. The skill is seeing the I/O the syntax hides.

Table of Contents¶

1. The obvious one
2. The helpful getter
3. The enrich helper
4. The lazy property
5. The membership filter
6. The recompute in the loop
7. The trap

Snippet 1 — The obvious one¶

# Python — a dashboard endpoint
def build_dashboard(user_ids):
    cards = []
    for uid in user_ids:                       # 500 ids
        profile = profile_service.fetch(uid)   # remote call
        stats = stats_service.fetch(uid)       # another remote call
        cards.append(render_card(profile, stats))
    return cards

Is there an N+1? Where? How would you fix it, and how many calls would the fix make?

def build_dashboard(user_ids):
    profiles = {p.id: p for p in profile_service.fetch_many(user_ids)}
    stats    = {s.id: s for s in stats_service.fetch_many(user_ids)}
    return [render_card(profiles[uid], stats[uid]) for uid in user_ids]

Snippet 2 — The helpful getter¶

// Java — generating a shipping manifest
List<Shipment> shipments = shipmentRepo.findReadyToShip();   // 1 query
StringBuilder manifest = new StringBuilder();
for (Shipment s : shipments) {
    manifest.append(s.getId())
            .append(" → ")
            .append(s.getDestination().getCity())            // looks innocent...
            .append("\n");
}

Is there an N+1? Where? How would you fix it, and how many calls would the fix make?

Snippet 3 — The enrich helper¶

// Go — building an activity feed
func buildFeed(ctx context.Context, posts []Post) []FeedItem {
    items := make([]FeedItem, 0, len(posts))
    for _, p := range posts {
        items = append(items, enrich(ctx, p))   // looks like pure CPU
    }
    return items
}

func enrich(ctx context.Context, p Post) FeedItem {
    author := userClient.GetUser(ctx, p.AuthorID)   // a remote call, inside the helper
    likes := likeClient.CountLikes(ctx, p.ID)       // another one
    return FeedItem{Post: p, Author: author, Likes: likes}
}

Is there an N+1? Where? How would you fix it, and how many calls would the fix make?

Snippet 4 — The lazy property¶

# Python — exporting an invoice report
class Order:
    def __init__(self, row):
        self.id = row["id"]
        self._customer_id = row["customer_id"]

    @property
    def customer(self):
        return customer_repo.get(self._customer_id)   # I/O on every access!

def export(orders):
    rows = []
    for o in orders:
        rows.append(f"{o.id},{o.customer.name},{o.customer.tier}")  # accessed TWICE
    return rows

Is there an N+1? Where? How would you fix it, and how many calls would the fix make?

def export(orders):
    ids = {o._customer_id for o in orders}
    customers = {c.id: c for c in customer_repo.get_many(ids)}   # 1 query
    rows = []
    for o in orders:
        c = customers[o._customer_id]            # one in-memory lookup
        rows.append(f"{o.id},{c.name},{c.tier}")
    return rows

Snippet 5 — The membership filter¶

// Go — filtering orders down to VIP customers
func vipOrders(orders []Order, vipIDs []int64) []Order {
    var out []Order
    for _, o := range orders {                 // n
        for _, id := range vipIDs {            // × m
            if o.CustomerID == id {
                out = append(out, o)
                break
            }
        }
    }
    return out
}

Is there an N+1? Where? How would you fix it, and how many comparisons would the fix make?

func vipOrders(orders []Order, vipIDs []int64) []Order {
    vip := make(map[int64]struct{}, len(vipIDs))
    for _, id := range vipIDs {
        vip[id] = struct{}{}
    }
    out := make([]Order, 0)
    for _, o := range orders {
        if _, ok := vip[o.CustomerID]; ok {
            out = append(out, o)
        }
    }
    return out
}

Snippet 6 — The recompute in the loop¶

# Python — scoring search results against a query
def rank(results, query):
    scored = []
    for r in results:                              # 50k results
        query_terms = set(query.lower().split())   # rebuilt every iteration
        idf = load_idf_table()                     # expensive load, every iteration
        score = sum(idf.get(t, 0) for t in query_terms if t in r.text)
        scored.append((score, r))
    return sorted(scored, reverse=True)

Is there an N+1? Where? How would you fix it?

def rank(results, query):
    query_terms = set(query.lower().split())   # once
    idf = load_idf_table()                     # once
    scored = [(sum(idf.get(t, 0) for t in query_terms if t in r.text), r)
              for r in results]
    return sorted(scored, reverse=True)

Snippet 7 — The trap¶

# Python — processing a small set of payment providers at startup
def healthcheck(providers):           # providers = the 3 payment gateways we support
    statuses = {}
    for p in providers:
        statuses[p.name] = p.ping()    # one network call per provider
    return statuses

Is there an N+1? Should you "fix" it?

What These Snippets Teach¶

The reviewer's instinct: find the expensive thing done once per item — and equally, know when leaving it alone is right.

Related Topics¶

• N+1 in Code → tasks.md — build the cures these snippets call for.
• N+1 in Code → senior.md — detecting the hidden N+1s (Snippets 2–4) with query counters and traces.
• N+1 in Code → professional.md — the trade-offs behind the trap (Snippet 7).
• Wrong Data Structure → find-bug.md — the scan-in-loop overlap (Snippet 5).
• Premature Optimization Traps → find-bug.md — why "fixing" Snippet 7 would be the real mistake.
• The database-performance, big-o-analysis, and caching-strategies skills.