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 4!
🏗 System Design: Availability vs. Consistency
Today’s System Design concept dives into the classic trade-off in distributed systems: Availability vs. Consistency, closely tied to the CAP Theorem.
✅ Availability
- Refers to the ability of a system to remain operational and provide services, even in the presence of failures.
- Measured in terms of uptime percentage.
- A highly available system ensures that users always get a response (no timeouts/errors), though the data might not always be the most recent.
📏 Consistency
- Guarantees that all clients see the same data at the same time.
- Important for maintaining data correctness and integrity.
- A strongly consistent system ensures that a read always reflects the latest write.
⚖️ The CAP Theorem
In distributed systems, you can only achieve two of the following three guarantees at the same time:
- Consistency (C) → Every read reflects the most recent write.
- Availability (A) → Every request receives a response (no errors).
- Partition Tolerance (P) → The system continues operating even if the network is unreliable.
Since network partitions are unavoidable, every distributed system must tolerate them. That leaves us with two design options:
-
CP (Consistency + Partition Tolerance)
- System waits for consistency, potentially sacrificing availability (timeouts, errors).
- Example: Banking systems where accuracy of transactions matters more than availability.
-
AP (Availability + Partition Tolerance)
- System prioritizes availability, even if it returns stale data.
- Example: Shopping carts or social feeds where being available is more important than strict consistency.
💭 My Thoughts
Understanding availability vs. consistency feels like a foundational milestone in system design. Distributed systems bring massive power and resilience but also force tough choices.
This concept reminds me that “perfect systems don’t exist” — every architecture has trade-offs. The skill lies in knowing when to sacrifice consistency for uptime, or uptime for correctness, depending on the business case.
💻 DSA Challenge: Container With Most Water
After digging into Availability vs. Consistency, I moved on to a classic two-pointer problem on LeetCode: 11. Container With Most Water.
⏳ Time spent: ~2+ hours
This one was tricky at first — but the two-pointer approach really clicked after testing some edge cases.
🔎 Understanding the Problem
You’re given an array of heights. Each element represents a vertical line on the x-axis. You need to choose two lines that, together with the x-axis, form a container that holds the most water.
Constraints:
- Width is determined by the distance between lines.
- Height is limited by the shorter of the two lines.
🧩 My Approach: Two-Pointer Technique
Step 1: Initialization
max_area = 0
left = 0
right = len(height) - 1
-
max_area: keeps track of the maximum water area. -
left: pointer at the start. -
right: pointer at the end.
Step 2: Main Loop
while left < right:
current_area = (right - left) * min(height[left], height[right])
max_area = max(max_area, current_area)
- Calculate area as
width × min(height[left], height[right]). - Update
max_areawhenever a bigger area is found.
Step 3: Move Pointers
if height[left] < height[right]:
left += 1
else:
right -= 1
- Always move the pointer at the shorter line, since moving the taller one won’t increase area.
Step 4: Return Result
return max_area
👨💻 Full Code Snippet
class Solution:
def maxArea(self, height: List[int]) -> int:
max_area = 0
left, right = 0, len(height) - 1
while left < right:
current_area = (right - left) * min(height[left], height[right])
max_area = max(max_area, current_area)
if height[left] < height[right]:
left += 1
else:
right -= 1
return max_area
✨ Key Takeaways
- The two-pointer method is optimal here — avoids brute force O(n²).
- Moving the smaller pointer is the key insight.
-
Tested with edge cases:
- Equal heights at ends.
- One very tall + many short lines.
Got much cleaner once I stopped trying to “track max height” and just trusted the pointer logic.
🙌 Final Thoughts
Day 4 gave me two powerful lessons:
- In System Design → trade-offs are unavoidable, especially between consistency and availability.
- In DSA → two-pointer techniques can massively reduce complexity when the problem involves “extremes” from both ends.
Slow but steady, I’m building confidence one day at a time 💪.
🤝 Let’s Connect!
If you enjoyed this breakdown, let’s chat! Drop a comment, share with others on the same path, or reach out with feedback. Your support keeps me motivated to keep learning daily 🚀.
Top comments (4)
You are doing good job keep on doing 👍.
thank you very much
Loved the clarity on CAP trade-offs..
Thank you