DEV Community: LearnHowToCode

Logging: Not More, but Meaningful – Log to Understand, Not Just Record

LearnHowToCode — Sun, 11 May 2025 08:10:11 +0000

One day, your system crashes. You open the dashboard and scan through the logs—only to be hit by a wall of noise:
10,000 lines of “User created.”
8,000 lines of “Processing…”
And somewhere, buried deep: Error: something went wrong.

You have no idea where the problem is. No clue which request each line belongs to. Everything blurs into static.

And then you realize: Unstructured logging is just noise.

Logging isn’t about writing down everything that comes to mind. It’s the art of collecting clues—so that when something breaks, you can trace what happened, where, and why.

First: Use Log Levels Properly

DEBUG: For low-level detail during development. Lines like “Received input…” or “Loop i = 4” belong only in dev or when debug is enabled.
INFO: For meaningful actions during normal operation: user login, order placed, message processed. This is your standard, low-anxiety log level.
WARN: For things that aren’t broken, but aren’t ideal: slow API responses, retries, missing configs that fall back to defaults. Worth watching—not panicking.
ERROR: Real problems:
Exceptions, failed transactions, connection drops, malformed data.
These should light up your dashboards, ping Slack, trigger PagerDuty—and demand attention when they spike.

Second: Always Tag Logs with request_id or trace_id
In modern systems, a single request may span 5–10 services. Without a common identifier linking logs, the trail goes cold.

You’ll see an error in Service D, but not know where it started. You’ll see “Processed” in Service A, but not know if it relates to the error.

Attaching request_id is your only way to trace the full journey. Add trace_id and span_id (via OpenTelemetry), and now you can measure how long each step took.

Third: Embrace Structured Logging
Don’t just log raw strings—use structured logs (e.g., JSON):

{
  "timestamp": "2025-05-06T14:23:12Z",
  "level": "INFO",
  "event": "user_created",
  "user_id": 1234,
  "request_id": "abc-xyz-123"
}

Structured logging lets you:

Search logs by user_id, event, or request_id
Filter, group, and visualize with ELK, Datadog, Sentry…
Build dashboards tracking event rates, error spikes, etc.

In a distributed system, structured logs are essential—you can’t rely on eyeballing plaintext anymore.

Finally: The Most Dangerous Log Is the One That Lies. It’s not the missing logs that hurt most. It’s thinking you have logs—when they’re wrong.

Logging errors in the wrong context
Logging without stack traces
Logging sensitive data (passwords, tokens)
Overlogging in production and choking memory or I/O
Logging just enough to mislead you in a crisis

A single careless log can stall your entire investigation—or worse, compromise your system.

Logging is not about memory. It’s about visibility. When you can’t "see" your system with your own eyes, logs become your lens.

✅ Log less, but log right.
✅ Log with context, structure, and clarity.
✅ Log like you’re telling a teammate what just happened—so they know where to look, what to fix, and why.

Further Reading

If you found this article helpful and you’re keen on optimizing algorithms and honing your algorithmic thinking, I highly recommend the book Algorithm Mindset. It doesn’t just walk you through real-world problem-solving, it also helps you cultivate an algorithmic mindset in the most intuitive way.

Read Replicas: Offloading Load by Sharing Reads

LearnHowToCode — Thu, 08 May 2025 10:45:55 +0000

When your system is still small, you have only one database. All operations — both reads and writes — go through the same path, and everything seems to flow naturally. But then the system starts to grow. Users multiply. The number of queries increases exponentially. And you will realize a simple truth: most of the requests are merely read operations.

Browsing products. Scrolling through a timeline. Searching for posts. Each of these actions consumes I/O, CPU, and memory resources on the database. At first, you may think, "It’s just reading — how heavy can it be?" But reads, when there are enough of them, can gradually and surely choke the system.

That’s when read replicas become a weapon you must consider.

The solution is conceptually simple: you replicate your primary database into multiple copies — replicas that serve read traffic only. The master database focuses on writing new data, while the replicas distribute the read load across multiple nodes, creating more open lanes for traffic to flow smoothly.

If you implement this correctly, the system will dramatically reduce the pressure on the master and greatly increase its read capacity.

But there’s no such thing as a free lunch.

Replication always introduces a delay — the so-called replication lag. When you write new data to the master, it takes a short amount of time for that update to synchronize to the replicas. And during that brief lag, users may see an outdated version of the data. They might update their profile but still see the old information when they reload. They might purchase a product but still see the item listed as "in stock" in their cart.

If you don’t understand replication lag, you might think your system is broken. If you do understand it, you’ll know: this is an acceptable trade-off for achieving higher scalability.

A high-load system doesn’t try to eliminate replication lag. It learns to live with it and manage it properly.

For example, for critical actions that require real-time data accuracy, such as confirming an order, you can design the system to read directly from the master. For less time-sensitive actions, like browsing public product catalogs, you can route reads to replicas.

This is an art of balance, not a rigid formula.

But lag is only part of the story.

You must also prepare for failover — the situation when the master database suddenly fails. When that happens, you need to act quickly: promote a replica to become the new master and update the system's routing accordingly.

Without a prepared failover strategy, a database failure can quickly spiral into system-wide chaos.

Proper failover requires strict management of the replication topology, continuous health monitoring of nodes, and either automated or at least semi-automated failover processes.

And in reality, executing a clean, consistent failover is no easy feat. Many systems have suffered prolonged downtimes simply because they underestimated this problem.

I want you to remember one thing:

Read replicas are not a magic wand. They are only powerful if you truly understand their nature, prepare the right way, and consciously accept their natural limitations.

You don’t scale reads infinitely just by adding more replicas. You scale reads properly when your system knows how to manage replication lag, route requests intelligently, and automate failover to keep the heart of your data beating steadily even when disruptions occur.

Further Reading

CAP Theorem – The Three Fronts You Can't Win All At Once

LearnHowToCode — Wed, 07 May 2025 02:53:07 +0000

In every engineer's dream, the ideal system would be:

Always consistent (data is perfectly synchronized at all times),
Always available (no errors, no timeouts),
And completely unaffected by network issues.

But reality is much harsher.

When you build a distributed system — a system with multiple nodes and servers communicating over a network — you’ll realize:

You can't have it all.
You must sacrifice at least one factor.

This is the essence of the CAP Theorem — one of the foundational principles that shapes all high-load systems.

CAP Theorem: At Its Core, It's About Trade-Offs

CAP stands for three properties:

Consistency (C):
Every node sees the same data at the same time.
Availability (A):
The system always responds to requests — even if only with a valid error — instead of staying silent or timing out.
Partition Tolerance (P):
The system continues to operate even when network partitions occur between nodes.

The CAP Theorem states:

When a network partition happens, you must choose between Consistency and Availability.
You cannot optimize for both simultaneously.

A Real-World Analogy: Bank Transactions Between Branches

Imagine this: You have two bank branches in two different cities, connected via a network. One day, the connection between the two branches is lost.

Now:

If you prioritize Consistency: The system will refuse any transaction because it can't guarantee synchronized data. Users will experience errors or failed transactions (Availability drops).
If you prioritize Availability: The system will still allow local transactions, saving them temporarily for later synchronization. But there’s a risk of temporary data inconsistency.

You can only choose one priority in this situation.

Three Types of Distributed Systems Under CAP

Depending on business needs, real-world systems make different trade-offs:

1. CP Systems (Consistency + Partition Tolerance)

Prioritize absolute data correctness, even if it means downtime.

Example: Banking systems, digital wallets.

When a network issue occurs → The system would rather reject a request than risk incorrect data.

2. AP Systems (Availability + Partition Tolerance)

Prioritize serving requests no matter what, accepting temporary inconsistency.

Example: Social networks, large marketplaces.

When a network issue occurs → Users can still post statuses or buy items, even if data synchronization lags behind temporarily.

3. CA Systems (Consistency + Availability)

These only exist in theory or in non-distributed systems (single-node setups or perfectly stable networks).

In real distributed systems, Partition Tolerance is non-negotiable.

Applying CAP in Real Systems

You must decide:

Prioritize Consistency when data errors could cause severe consequences (e.g., banks, financial transactions).
Prioritize Availability when user experience is critical, and temporary inconsistency is acceptable (e.g., newsfeeds, likes, comments).

There’s no absolute right or wrong.
Only choices that match your business goals and user expectations.

Practical Example: Liking a Post on Social Media

You tap the "Like" button on a post.

If the system prioritizes Availability, the Like icon updates instantly on your screen — even if synchronization with other servers isn't complete yet.
If the system prioritizes Consistency, you might have to wait 1–2 seconds or even see an error if the server can't confirm the action immediately.

Every choice comes with its own cost.

TL;DR

Building a high-load system is not just about technical excellence.
It’s an art of choosing wisely and accepting trade-offs.

When you understand CAP, you stop demanding "everything at once."
You start asking smarter questions:

"What do I need to prioritize here?"
"Is the added latency acceptable for users?"
"What level of consistency is good enough?"

Further Reading

Stop Over-Looping: A Practical Primer on the Two-Pointer Technique

LearnHowToCode — Tue, 06 May 2025 09:25:10 +0000

If your code still leans on O(n²) loops to scan arrays, the Two-Pointer technique is one of the simplest ways to unlock linear-time speed-ups—without fancy data structures or extra memory. In this post I’ll take you from a native solution to an elegant O(n) approach you can drop straight into production.

⸻

1. When You Actually Need to Optimize

Picture this:
You’re on call. Everything’s fine — until it’s not.

Latency suddenly spikes in one of your critical APIs. You dive into the logs and find the issue: a tiny helper function that’s supposed to “find two numbers that add up to X.”

The code looks clean. Easy to understand. The problem? It’s using two nested loops — O(n²) time.

When the dataset was small, nobody noticed. Now, under real traffic, that tiny function is wrecking your performance.

You don’t have time to redesign the whole system. You don’t want to pull in complicated data structures or blow up memory usage.

You need a fix. Fast. Safe. Production-ready.

That’s where the Two Pointers technique comes in. Simple idea, huge payoff.

2. The Classic Trap That Slows Everything Down

Here’s what the original code probably looks like:

// O(n²) brute-force
function hasPairBrute(arr, target) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = i + 1; j < arr.length; j++) {
      if (arr[i] + arr[j] === target) return true;
    }
  }
  return false;
}

Clean? Yeah.
Correct? Sure.
Fast? Not even close.

If your array has 200,000 items, this little function needs to check around 20 billion pairs. Even with modern hardware, your server fans will start sounding like a jet engine.

3. How Two Pointers Saves the Day

Here’s the upgrade:

// O(n log n) if sorting is needed; O(n) after that
function hasPairTwoPointers(arr, target) {
  arr.sort((a, b) => a - b);           // 1️⃣ optional
  let left = 0, right = arr.length - 1;
  while (left < right) {               // 2️⃣
    const sum = arr[left] + arr[right];
    if (sum === target) return true;   // 3️⃣
    if (sum < target) left++;          // 4️⃣
    else right--;                      // 5️⃣
  }
  return false;
}

Here’s the idea:
1️⃣ Sort the array if needed. (Sometimes the data is already sorted upstream.)
2️⃣ Set two pointers — one at the start, one at the end.
3️⃣ Check the sum of the two numbers.
4️⃣ If the sum is too small, move the left pointer right.
5️⃣ If the sum is too large, move the right pointer left.

No fancy data structures. No extra memory. Just smart movement from both ends toward the middle.

4. So How Much Faster Are We Talking?

Time Complexity: O(n log n) for sorting, O(n) for the two-pointer scan.
Space Complexity: O(1) — no extra arrays, no extra maps.

Compared to 20 billion brute-force checks, this is like swapping a bicycle for a rocket ship.

TL;DR

Next time you see nested loops, ask yourself:

“Can I solve this with Two Pointers instead?”

If you can, you’ll make your code faster, cleaner, and way more scalable — without needing fancy tools or extra memory.

🚀 Thanks for reading!

If you enjoyed this post, leave a ❤️ or drop a comment

Further Reading