Daily DSA and System Design Journal – 3

This content originally appeared on DEV Community and was authored by I.K

Hello, I’m continuing my journey of daily learning, focusing on System Design concepts (via the roadmap.sh System Design Roadmap) and then tackling DSA challenges on LeetCode. This is DAY 3!

System Design: Latency vs. Throughput

Today’s System Design concept dives into two crucial metrics for understanding system performance: Latency and Throughput.

Latency

This is the time it takes for a system to respond to a single request.
Think of it as: “How long does it take to get an answer?”

• Usually measured in milliseconds (ms) or microseconds (µs)
• High latency → slower response times
• Causes: network delays, slow database queries, inefficient code

Throughput

This is the number of requests a system can handle in a given period.
Think of it as: “How many questions can you answer in a minute?”

• Measured in Requests Per Second (RPS) or Transactions Per Second (TPS)
• Low throughput → system not handling many requests
• Limited by: bandwidth, CPU/memory capacity, inefficient algorithms

Relationship Between Them

• Improving throughput doesn’t always reduce latency, and vice-versa.
• Sometimes optimizing for one can negatively impact the other.
• The right balance depends on your system’s requirements.

Example: Coffee Shop

• Latency: The time it takes for a barista to make one cup of coffee.
• Throughput: The number of cups of coffee the shop can serve per hour.
• Reduce latency → buy a faster espresso machine.
• Increase throughput → hire more baristas.

My Thoughts

I’m starting to see how these concepts shape efficient and scalable systems. It’s not just about making things “fast,” but also ensuring systems can handle large volumes of requests without breaking down.
Being able to identify bottlenecks and trade-offs is key in system design!

DSA Challenge: Regular Expression Matching

After wrapping my head around latency and throughput, I switched gears to a challenging LeetCode problem: 10. Regular Expression Matching.

Time spent: ~3 hours
This problem definitely stretched me — recursion + regex matching is no joke!

Understanding the Problem

• . → matches any single character
• * → matches zero or more of the preceding element
• The match must cover the entire string

My Approach: Recursion

I used recursion to simulate the matching process.

• Helper function: match(i, j) → checks if s[i:] matches p[j:]
• Base case: if pattern p is empty, s must also be empty

• Recursive cases:

  • If next pattern char is *, two choices:

1. Skip `*` (zero matches)
2. If first char matches, consume one char from `s` and recurse

• Otherwise, match one char and move forward

Code Snippet

class Solution:
    def isMatch(self, s: str, p: str) -> bool:
        def match(i, j):
            if j == len(p):
                return i == len(s)
            first_match = i < len(s) and (p[j] == s[i] or p[j] == '.')
            if (j + 1) < len(p) and p[j + 1] == '*':
                return (match(i, j + 2) or
                        (first_match and match(i + 1, j)))
            else:
                return first_match and match(i + 1, j + 1)
        return match(0, 0)

Key Takeaways

• Recursion is powerful for pattern-matching problems.
• You must carefully handle all cases and edge conditions.
• Debugging forced me to really internalize the logic.
• Next step: try Dynamic Programming to optimize recursion.

Final Thoughts

Day 3 was tough but rewarding. On the System Design side, I learned how latency and throughput differ yet complement each other. On the DSA side, I leveled up my recursive problem-solving skills with regex matching.

This daily grind is paying off — small steps each day, building towards mastery.

Let’s Connect!

I’m really enjoying this journey. If you found this post useful or have suggestions, feel free to comment, share, or connect. Your support keeps me motivated to keep learning daily!

This content originally appeared on DEV Community and was authored by I.K