DEV Community: Ace-2504

The Bugs That Hide Behind "It Works": Debugging a Multithreaded C++ Proxy Server

Ace-2504 — Mon, 08 Jun 2026 08:37:27 +0000

As a student, one of the biggest lessons I've picked up is that a program which compiles and runs is not the same as a program that is correct. It really hit home while I was building a multithreaded C++ network proxy server — a project that authenticates users with SHA-256, enforces role-based website filtering, and caches HTTP responses using a custom LRU cache.

The happy path worked on pretty early. The real learning started when I went looking for the bugs that don't announce themselves — the ones that only show up under concurrency, fragmented packets, or heavy load. Here are four of the most interesting and challenging issues I ran into and how I fixed them.

1. The Thread Pool That Never Detached

The proxy spawns 20 persistent worker threads at startup. The idea was simple: create the workers, then detach them from the main thread so they run independently.

The bug was an ordering mistake. My detachment loop ran before the threads were created:

for (auto& t : workers) t.detach();   // workers is still EMPTY here
workers.emplace_back(...);            // threads created afterward

Because the vector was empty when the loop ran, the iteration did nothing — the threads were never actually detached. It's the kind of bug that compiles cleanly, passes a quick test, and then causes resource and lifecycle problems once the server runs for a while.

The fix: I changed the order of the code. First, I created all the worker threads. Then, I detached them. What I learned: when working with threads, the order of setup steps matters. It is part of making the program correct, not just a small coding detail.

2. A Data Race Hiding Inside the Logger

My logging system looked thread-safe. Every write to proxy.log was guarded by a std::lock_guard<std::mutex>, so 20 threads writing at once could never scramble the file.

But the timestamps came from ctime(&now). Under POSIX, ctime returns a pointer to a globally shared static buffer. My mutex protected the file stream — it did NOT protect that hidden global buffer. So two threads formatting timestamps at the same time could corrupt each other's strings, even though the file writes themselves were perfectly safe.

The fix: switched to the thread-safe version, ctime_r(), which writes into a buffer. The lesson was a subtle one: locking the obvious shared resource isn't enough. You also have to think about the shared state hiding inside the standard library functions you're calling.

3. The TCP Read That Assumed Too Much

My request handler made a single call:

recv(client_socket, buffer.data(), BUFFER_SIZE, 0);

This assumes that one recv() gives you one complete HTTP request. TCP makes no such promise. TCP is a byte stream, not a message protocol — a request can arrive split across several packets. If a header got cut in half, my request.find("Host:") parsing would just fail, and a valid request would get dropped for no obvious reason.

The fix: replaced the single read with a loop that keeps calling recv() until the \r\n\r\n header terminator has fully arrived. For my proxy, this handled the request headers; a fuller HTTP implementation would also need to handle bodies using Content-Length or chunked transfer encoding. This turned out to be one of the most common (and most underestimated) mistakes in network programming: treating a stream like a neat sequence of separate messages.

4. Defending Against Hanging Connections

Worker threads are a limited resource — I only have 20. A single unresponsive remote server that never closes its connection could tie up a worker forever, and 20 of those stalls would quietly take the whole proxy offline.

My defense was setting a receive timeout with setsockopt() using SO_RCVTIMEO, set to one second. If a remote server goes quiet mid-response, the thread frees itself instead of hanging forever. Combined with proper HTTP status codes sent back to the client — 502 Bad Gateway when DNS resolution fails, 504 Gateway Timeout when the upstream stalls — the proxy fails gracefully instead of dying silently.

What Debugging Concurrent Code Taught Me

The common thread across all four bugs is the same: concurrency and networking break the assumptions that work perfectly in single-threaded, single-packet test runs.

Setup order is part of correctness, not a detail.
A mutex protects what it wraps — and nothing else, including hidden global state.
The network gives you a byte stream, never a tidy message.
Limited resources need timeouts, or one bad peer takes everything down.

None of these bugs threw an error or crashed the compiler. They lived in the gap between "it runs" and "it is correct" — and for me, closing that gap has been the most rewarding part of learning systems programming.

If you've built low-level networked systems in C++, I'd love to hear which subtle concurrency bug cost you the most time to track down.

Turning Behaviour into Climate Accountability

Ace-2504 — Tue, 24 Feb 2026 18:57:22 +0000

One winter morning in Delhi, the AQI crossed 460 — officially hazardous. Schools shut. Hospitals filled. Transport slowed. Offices continued. Every day, millions of environmental decisions are made. Whether to drive or take public transport. Whether to allow remote work. Whether to burn waste or compost. These choices influence emissions — yet we rarely measure the pollution that did not happen because of them.

That is the missing piece.

Most environmental systems measure what exists: current emissions, fuel consumption, air quality levels. They do not formally measure avoided emissions. Counterfactual attribution addresses this gap by comparing two clearly defined scenarios:

Business-as-usual baseline — what would have happened
Verified alternative — what actually occurred

Impact = Baseline − Verified Alternative.

A Practical Example: Urban Commuting
Consider a professional living 14 km from work. A 28 km daily round trip in a petrol car (≈ 120 g CO₂/km) results in about 3.36 kg CO₂ per day. Across 240 working days, that equals approximately 806 kg CO₂ annually. That is the baseline.

Now introduce two behavioural shifts:

Work from home two days per week → avoids ~322 kg per year
Shift to electric metro on remaining days (≈ 15 g CO₂/km) → saves ~423 kg

Total avoided emissions ≈ 745 kg CO₂ Remaining footprint ≈ 61 kg

That is a reduction of over 90%, derived from a measurable behavioural delta — not offsets, not assumptions.

If the remaining 61 kg is neutralised through verified sequestration (e.g., monitored urban trees at ~10 kg per tree annually), the commuting footprint approaches net zero.

Baseline → Reduction → Net Impact. Each step is quantifiable.

Preventing Double Counting
A critical issue emerges: duplication.

If an employee reports work-from-home reductions, and their employer's HR department also reports the same reduction in ESG disclosures, total claimed impact exceeds actual impact.

To prevent this, the framework introduces a non-duplication constraint.

Let:

Δ_total = Verified avoided emissions
C_i = Claim attributed to entity i

The system enforces:

Σ Cᵢ ≤ Δ_total

No combination of claims may exceed the verified delta.

Each reduction event is assigned:

A unique registry ID
A defined ownership tag
A claim status flag

Work-from-home emissions may be attributed to the enabling institution, while individual dashboards reflect behavioural contribution — without generating duplicate claimable credits unless formally allocated.

This ensures:

Measurability
Additionality
Non-duplication
Audit defensibility

Without duplication control, avoided-emission accounting collapses under verification.

Enterprise Implications
Most sustainability reports rely on estimated participation and averaged emission factors. A verification-first counterfactual architecture instead:

Establishes defined baselines
Verifies behavioural change in a privacy-preserving manner
Models avoided emissions at corridor level
Applies attribution constraints
Produces audit-ready metrics

Under such a system, work-from-home is not merely HR flexibility. It becomes measurable climate infrastructure.

The Broader Shift
This logic applies anywhere a conservative baseline can be defined:

Agricultural burn avoidance
Household waste diversion
Fuel switching in buildings
Distributed renewable adoption
Industrial efficiency upgrades

For decades, climate systems focused on measuring what we emit.

The next frontier is measuring what we prevent — without inflation, without duplication, and without ambiguity.

Climate accountability will not be built on slogans.

It will be built on baselines, constraints, and verifiable delta.

Patent Filed, 2026. A technical paper detailing the verification-first MRV architecture, statistical bias bounds, and attribution constraints is under preparation.

How McKinsey Frameworks Fixed My Scattered API

Ace-2504 — Sun, 04 Jan 2026 15:51:33 +0000

While building the backend for Ace Rentals, I realized that my authorization logic, although functionally correct, felt increasingly fragile. Ownership checks were scattered across multiple routes, duplicated in several places, and easy to forget when adding new endpoints. Over time, this made the system harder to reason about and increased the risk of subtle security gaps.

Rather than continuing with incremental fixes, I stepped back and redesigned authorization as a system-level concern using centralized middleware. This article explains how I identified the issue, how I reasoned about the redesign, how it was implemented, and what improved as a result.

Previous Authorization Approach

Authorization checks were implemented directly inside individual route handlers. Each protected endpoint contained its own logic to verify whether the current user was allowed to perform the requested action.

While this approach worked initially, it introduced several challenges as the application grew:

The same ownership logic was copied across multiple routes
Route handlers mixed business logic with authorization concerns
Adding new endpoints required manual checks, increasing the chance of mistakes

The system did not fail outright, but correctness increasingly depended on careful and repetitive implementation.

Identifying the Design Issue

The problem was not a missing check or a faulty condition—it was a structural issue. Authorization was treated as an implementation detail instead of a rule enforced consistently by the architecture.

This meant security relied on developer memory rather than system guarantees. As the number of routes increased, so did the effort required to maintain consistency and confidence in the design.

Design Analysis and Decision-Making

To avoid patching individual routes, I analyzed the problem at a design level.

I used MECE-style analysis to verify whether authorization was applied consistently across all relevant routes. This exposed gaps and overlap in enforcement.
I compared alternative approaches and found that centralized middleware offered the best balance between reuse, clarity, and maintainability.
I set clear constraints for the refactor—no change in behavior, minimal surface area, and focused scope—to avoid unnecessary complexity.

This structured approach helped ensure the redesign addressed the root cause rather than its symptoms.

Authorization Redesign and Implementation

Authorization was elevated to a system-level concern and implemented through middleware:

Ownership checks were consolidated into a single, reusable middleware function
API endpoints were reorganized around resources rather than actions, improving clarity
Authorization was enforced early in the request pipeline, before any business logic executed

With this setup, routes automatically inherit authorization rules. Developers no longer need to remember to reapply checks when adding or modifying endpoints.

Observed Impact of the Redesign

The redesign produced clear and measurable improvements:

Authorization logic now exists in one place instead of being duplicated
All protected routes enforce authorization consistently by default
Maintenance effort and regression risk were significantly reduced
Resource relationships are clearer through resource-based routing
Route handlers are simpler and focus only on business logic

A qualitative review showed that core domain logic is stable. Remaining risk is isolated to shared authorization middleware, where it is explicit, visible, and easier to reason about.

Key Learning

Repeated logic is often a signal of a deeper design issue. Treating security as a structural concern—rather than a manual step—leads to systems that are easier to maintain, extend, and trust over time.

Design Decisions and Learnings

This article provides a high-level summary of the decisions and outcomes from redesigning authorization in Ace Rentals.

For a deeper look into my learning experience—including diagrams, structured reasoning, trade-offs, and implementation details—you can read the full write-up here:

👉 https://ace-2504.github.io/api-design-blog/

The full version documents the complete thought process and lessons learned while designing and refactoring the system.