Forem: I.K

Showing up before you're ready

I.K — Tue, 17 Mar 2026 13:33:22 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

The Beginning: Learning in Public

I was months into posting about system design before anyone really noticed. No strategy, no audience. Just a running tab of things I was figuring out in public, shared whether or not I felt ready to share them.

The resources weren't always great. I was piecing together half-written articles and old YouTube videos, working with what I had. That part was manageable. What nobody warned me about was motivation—how unreliable it is, how fast it dries up.

Three weeks in, the energy fades and the excuses come easy. What saved me wasn't some dramatic discipline overhaul. It was lowering the bar:

Five minutes counted.
One post counted.
Showing up badly beat not showing up at all.

The Power of Consistency

That consistency compounded. Since then, I've seen:

Over 600 followers.
A potential ambassadorship.
Hackathon wins and communities that opened doors I didn't know existed.

I wasn't the most talented person in those rooms. I was just the one who kept coming back.

Lessons Learned (The Hard Way)

The lessons weren't glamorous. Don't leave things to the last minute. Fourteen hours in one desperate sitting is no substitute for two focused hours every day: your brain rewards rhythm, not sprints. The work you do exhausted and frantic rarely survives the morning.

And then there's connections—the lesson that surprised me most. I used to think networking was a game for people who already belonged. I was wrong.

Fortune doesn't just favor the bold; it specifically favors the visible.

You have to put yourself out there before you feel ready: speak when your voice shakes, walk into rooms where you know no one. Every opportunity that changed something for me came from one of those uncomfortable moments.

A Note to the Underrepresented

If you're under-resourced, flying blind, or unsure whether you belong: the gap usually isn't talent. It's consistency and visibility. Take the speaking slot. Post the thing. Not because you're ready, but because showing up is how you get ready.

Daily DSA and System Design Journal - 16

I.K — Sat, 01 Nov 2025 17:07:50 +0000

🔥 Day 16 — Greedy Growth & Global Pulls 🌍⚙️

Greedy algorithms and CDNs both thrive on balance — optimizing decisions locally to maximize global efficiency. Today’s combo: maximizing distinctness in arrays and minimizing latency with pull-based caching.

🧩 DSA Problems [1 hr]

Problem: 3176. Find Maximum Distinct Elements After Operations (the problem you described matches this one)

💡 Approach: Greedy

🧠 Intuition

We want to maximize the number of distinct elements in an array after at most one operation per element,
where each element nums[i] can be changed by any value in the range [nums[i] - k, nums[i] + k].

Key idea:

After applying all operations, all numbers lie within [min(nums) - k, max(nums) + k].
To make as many unique numbers as possible, we should assign the smallest valid unused value to each number.

🪜 Step-by-Step Greedy Process

Sort the array in ascending order.
Initialize a variable prev = -inf to represent the last assigned value.
For each number in sorted order:

Its valid range after operations is [num - k, num + k].
Choose the smallest possible value that’s still greater than prev:
```
 curr = min(max(num - k, prev + 1), num + k)
```
If curr > prev, increment the count and set prev = curr.

This ensures that every element takes the earliest distinct spot available.

💻 Code Implementation

import math

class Solution:
    def maxDistinctElements(self, nums: List[int], k: int) -> int:
        nums.sort()
        cnt = 0
        prev = -math.inf

        for num in nums:
            curr = min(max(num - k, prev + 1), num + k)
            if curr > prev:
                cnt += 1
                prev = curr

        return cnt

⚙️ Complexity

Measure	Complexity
⏱ Time	O(n log n) — due to sorting
💾 Space	O(log n) — typical for in-place sorting

🧠 Insights

This greedy algorithm ensures local optimality per element, leading to global optimal distinctness.
It parallels interval scheduling — minimizing conflicts while maximizing utilization.
Alternative view: we’re assigning each element a unique “slot” within its valid range.

🌍 SYSTEM DESIGN — Roadmap.sh [1 hr]

🧭 Pull CDNs

Pull CDNs automatically fetch and cache your content on demand — that is, only when users request it for the first time.

When a user requests content (like an image or CSS file):

The CDN checks if it already has a cached copy.
If not, it pulls it from your origin server.
The content is cached and served to future users until it expires (based on TTL).

⚙️ How It Works

Clients access resources via CDN URLs (e.g., cdn.example.com/images/logo.png).
The CDN routes the request to the nearest edge node.
If the content is cached and valid, it’s served instantly.
Otherwise, it’s fetched from the origin, cached, and then served.

🕓 TTL (Time To Live)

Determines how long cached content remains before it’s revalidated or re-fetched.
Choosing a good TTL balances freshness (short TTL) vs. efficiency (long TTL).

✅ Pros

Hands-off caching — no need to push content manually.
Great for dynamic or frequently accessed resources.
Balances load across global edge servers.

⚠️ Cons

First request latency — the initial user experiences a delay while the content is fetched.
Redundant traffic — if TTLs expire too soon, the same files may be re-fetched repeatedly.
Possible staleness — if content changes faster than cache invalidation.

💡 Ideal Use Cases

Use Case	Reason
High-traffic websites	Frequent access keeps caches warm
APIs serving static responses	Edge caching reduces origin hits
Video or image-heavy apps	Large content benefits from proximity caching

🧩 DSA ↔ System Design Analogy

DSA Concept	CDN Concept
Assigning smallest valid distinct value	Fetching content lazily, only when needed
Greedy range compression	Cache-space optimization
Avoiding duplicates via `prev` tracking	Avoiding redundant pulls via TTL

Both operate on lazy evaluation principles — do the minimal necessary now to maximize global efficiency later. ⚙️

✅ Day 16 Summary

Greediness isn’t always bad — when used smartly, it leads to global harmony. Whether assigning numbers or caching content, optimal local choices build global distinctness and efficiency. 🚀

Daily DSA and System Design Journal - 15

I.K — Fri, 31 Oct 2025 21:31:40 +0000

🧩 Day 15 — Sum of Good Subsequences & CDN Fundamentals

🧠 DSA Problems [1 hr]

Problem: 3351. Sum of Good Subsequences

💡 Approach: Dynamic Programming on Value Links

🧠 Intuition

We define two key state trackers:

count[a] — number of good subsequences ending with a.
res[a] — total sum of all subsequences ending with a.

For each number a in the array:

We can start a new subsequence with a.
Or extend subsequences ending with a - 1 and a + 1.

Hence,

count[a] = count[a-1] + count[a+1] + 1

Each of these subsequences contributes additional sums based on their totals and the value a:

res[a] = res[a-1] + res[a+1] + a * (count[a-1] + count[a+1] + 1)

We take modulo 10^9 + 7 to keep values bounded.
Finally, the total sum of all subsequences is sum(res.values()).

💻 Code Implementation

class Solution:
    def sumOfGoodSubsequences(self, A: List[int]) -> int:
        count = Counter()
        res = Counter()
        mod = 10 ** 9 + 7

        for a in A:
            count[a] += count[a - 1] + count[a + 1] + 1
            count[a] %= mod

            res[a] += res[a - 1] + res[a + 1] + a * (count[a - 1] + count[a + 1] + 1)
            res[a] %= mod

        return sum(res.values()) % mod

⚙️ Complexity

Measure	Complexity
⏱ Time	O(n)
💾 Space	O(n)

🧩 Key Insight

The solution uses local adjacency relationships (a-1, a+1) to form global subsequence sums.
This is a clean example of DP with aggregation via counters instead of full DP arrays — space-efficient and value-oriented.
The transitions mimic propagation through neighboring states — a pattern common in DP, graph traversal, and even distributed systems.

🌍 SYSTEM DESIGN — Roadmap.sh [1 hr]

🌐 Content Delivery Networks (CDNs)

A CDN is a globally distributed network that serves web content from servers closer to users, drastically improving latency and scalability.

When you load a site like www.netflix.com, your assets (images, CSS, JS, videos) are often fetched from a nearby CDN edge node — not from Netflix’s origin servers.

⚙️ How It Works

A client requests a resource (e.g., image or video).
DNS resolves the domain to the nearest CDN edge server.
If cached, content is served immediately.
If not, the edge server fetches it from the origin server, caches it, and serves the user.

This reduces latency, distributes load, and saves bandwidth at the origin.

🧱 Types of CDNs

🔹 Push CDN

Content is pushed manually or via automation to CDN nodes when it changes.
You control cache invalidation and content updates.
Best for sites with low traffic or infrequent updates.
✅ Pros: Less redundant traffic, predictable storage.
⚠️ Cons: Manual management, risk of stale content.

🔹 Pull CDN

CDN fetches content on demand when requested for the first time.
Cached locally afterward for future users.
Ideal for high-traffic or dynamic sites.
✅ Pros: Easier setup, automatic caching.
⚠️ Cons: First-request latency, possible redundancy if TTL is too short.

⏳ TTL (Time To Live)

Each cached item has a TTL — after which it expires and must be re-fetched from the origin.
Finding the right TTL is crucial for balancing freshness vs. efficiency.

⚖️ CDN Trade-offs

Advantage	Disadvantage
⚡ Faster content delivery	💰 Extra cost based on bandwidth usage
🧭 Global scalability	🕓 Risk of stale content if updates happen before TTL expires
🧱 Reduced load on origin servers	🔗 Requires rewriting URLs for CDN routing

🔍 Example Providers

Cloudflare — strong free tier, DDoS protection
AWS CloudFront — deep AWS integration
Akamai, Fastly, Google Cloud CDN — high-performance enterprise-grade CDNs

🧠 Reflection

Today’s DSA and System Design topics beautifully align:

DSA Concept	CDN Analogy
Local adjacency propagation	Content caching propagation across edge nodes
Dynamic aggregation via neighbors	Dynamic content refresh via TTL and caching rules
O(1) lookups via Counter	Constant-time retrieval via global CDN caches

Both rely on localized computation to achieve global efficiency.

✅ Day 15 Summary:

From subsequences to CDNs — efficiency grows when we connect adjacent states and cache intelligently. 🚀

Daily DSA and System Design Journal - 14

I.K — Thu, 30 Oct 2025 16:28:44 +0000

🧠 Day 14 — Adjacent Patterns & Domain Resolution

🧩 DSA Problems [1 hr]

Problem: 3350. Adjacent Increasing Subarrays Detection II

💡 Approach: One-time Traversal

🧠 Intuition

We’re looking for adjacent strictly increasing subarrays — essentially, zones where the array keeps climbing before it resets.

We maintain two counters throughout one pass:

cnt — current increasing streak
precnt — previous streak length

Whenever the sequence stops increasing (nums[i] <= nums[i-1]):

the previous count becomes precnt
we reset cnt to 1

At every step, there are two possible adjacent subarray pairs to consider:

Current vs. Previous Segment: max potential = min(precnt, cnt)
Single Extended Segment: when both lie within one long increasing run, potential = cnt // 2

By tracking both, we find the maximum adjacent pattern size in a single linear scan.

💻 Code

class Solution:
    def maxIncreasingSubarrays(self, nums: List[int]) -> int:
        n = len(nums)
        cnt, precnt, ans = 1, 0, 0
        for i in range(1, n):
            if nums[i] > nums[i - 1]:
                cnt += 1
            else:
                precnt, cnt = cnt, 1
            ans = max(ans, min(precnt, cnt))
            ans = max(ans, cnt // 2)
        return ans

⚙️ Complexity

Measure	Complexity
⏱ Time	O(n) — single traversal
💾 Space	O(1) — constant memory

🔍 Key Learnings

One-pass algorithms thrive on state compression — carrying only the info that truly matters.
Understanding segment relationships (current vs. previous) simplifies multi-phase problems.
Sometimes, the simplest recurrence hides the deepest efficiency.

🌍 SYSTEM DESIGN — Roadmap.sh [1 hr]

🌐 Domain Name System (DNS)

The Domain Name System is the phonebook of the internet — translating human-readable domain names into IP addresses that machines can understand.

When you type www.example.com in your browser, DNS resolves it to something like 93.184.216.34.

🧭 Hierarchical Architecture

Root DNS Servers — top-level, directing queries to TLD (Top-Level Domain) servers.
TLD Servers — responsible for domains like .com, .org, .net, etc.
Authoritative DNS Servers — final source for a given domain’s records.

Your device or local resolver caches results to avoid redundant lookups — governed by TTL (Time To Live).

📑 Common DNS Records

Record Type	Purpose
🧭 A	Maps domain to IPv4 address
🧭 AAAA	Maps domain to IPv6 address
📬 MX	Mail Exchange — email routing
🌍 CNAME	Canonical Name — points to another domain
🧾 NS	Name Server — specifies authoritative DNS servers

🚀 Managed DNS Providers

Modern systems often use managed DNS to add reliability and routing intelligence.
Examples include:

⚖️ Routing Policies

Policy Type	Description
⚖️ Weighted Round Robin	Distribute traffic based on server weights — useful for load balancing or A/B testing.
🕓 Latency-Based Routing	Direct users to the server with the lowest network latency.
📍 Geolocation Routing	Route users to the geographically closest data center.

🧠 Reflection

Both today’s topics — array traversal and DNS resolution — rely on hierarchy and memory.

The algorithm builds meaning incrementally — one element at a time.
DNS builds resolution hierarchically — one level at a time.

Both turn complex discovery into efficient lookup.

✅ Day 14 Summary:

Whether in data or domains, efficient systems remember just enough and resolve just in time.

Daily DSA and System Design Journal - 13

I.K — Tue, 28 Oct 2025 21:44:36 +0000

🧠 Day 13 — Bitmasking & Background Job Communication ⚙️

🧩 DSA Problems [1 hr]

Problem: 3003. Maximize the Number of Partitions After Operations

💡 Approach: Bitwise Operations + Preprocessing + Enumeration

🧠 Intuition

We can modify at most one character in the string.
Without modifications, we can compute all valid partitions easily.
When we introduce one modification, only its local segment changes — everything before and after it remains unaffected.

To analyze this efficiently:

We split the problem into a left segment and right segment around the position of modification.
Each segment tracks:
- 🧩 Number of splits
- 🧮 Character mask (bitwise representation)
- 🔢 Count of distinct characters

Using bit operations lets us quickly track which characters exist in each split.

We then simulate all modification positions and compute the best outcome.

💻 Code

class Solution:
    def maxPartitionsAfterOperations(self, s: str, k: int) -> int:
        n = len(s)
        left = [[0] * 3 for _ in range(n)]
        right = [[0] * 3 for _ in range(n)]

        num, mask, count = 0, 0, 0
        for i in range(n - 1):
            binary = 1 << (ord(s[i]) - ord("a"))
            if not (mask & binary):
                count += 1
                if count <= k:
                    mask |= binary
                else:
                    num += 1
                    mask = binary
                    count = 1
            left[i + 1][0] = num
            left[i + 1][1] = mask
            left[i + 1][2] = count

        num, mask, count = 0, 0, 0
        for i in range(n - 1, 0, -1):
            binary = 1 << (ord(s[i]) - ord("a"))
            if not (mask & binary):
                count += 1
                if count <= k:
                    mask |= binary
                else:
                    num += 1
                    mask = binary
                    count = 1
            right[i - 1][0] = num
            right[i - 1][1] = mask
            right[i - 1][2] = count

        max_val = 0
        for i in range(n):
            seg = left[i][0] + right[i][0] + 2
            tot_mask = left[i][1] | right[i][1]
            tot_count = bin(tot_mask).count("1")
            if left[i][2] == k and right[i][2] == k and tot_count < 26:
                seg += 1
            elif min(tot_count + 1, 26) <= k:
                seg -= 1
            max_val = max(max_val, seg)
        return max_val

⚙️ Key Learnings

Bitmasking enables constant-time distinct character tracking.
Dividing problems into left and right contexts simplifies otherwise complex state management.
Enumerating possible modifications systematically ensures you don’t miss edge cases.

🏗 System Design — Roadmap.sh [1 hr]

💬 Returning Results from Background Jobs

Background jobs often run asynchronously — decoupled from the main request-response cycle.
But what happens when the caller needs to know if the background task:

finished successfully? ✅
failed? ❌
or made progress? 🔄

That’s where communication mechanisms come in.

🧩 Common Strategies

Method	Description
🧾 Status Store	The job writes its progress or results to a shared datastore (DB, Redis). The UI polls or queries it.
📬 Reply Queue	A “reply-to” queue receives messages from the job — includes `ReplyTo` and `CorrelationId` for mapping results to requests.
🌐 API Endpoint	The job exposes an API for clients to request status updates or results.
🔔 Callback / Webhook	The job calls back to the client via API or publishes an event when it completes.

🧠 Example Scenarios

🧮 Report Generation: The user triggers a report → background job runs → result stored in S3 → UI polls until ready.
🔄 Machine Learning Pipeline: Background task publishes progress to a queue; dashboard listens for updates.
📦 Order Processing: System publishes “order completed” event via a message bus; microservices subscribe to react accordingly.

⚠️ Design Considerations

Concern	Description
🧱 Reliability	Messages or writes can fail — implement retries and acknowledgements.
🧩 Idempotence	Duplicate completion messages shouldn’t cause inconsistencies.
⏳ Timeouts & TTLs	Define how long clients should wait for results.
📡 Scalability	For large systems, prefer async event-driven feedback over polling.

🧠 Reflection

This day beautifully mirrors the DSA concept:

In the algorithm, you used bit-level precision to track states efficiently.
In system design, you used communication-level precision to synchronize async processes.

Both are about smart tracking and controlled feedback — small signals, big coordination.

✅ Day 13 Summary:

Progress isn’t just computation — it’s communication. Systems (and developers) that report back effectively scale gracefully. 🚀

Daily DSA and System Design Journal - 12

I.K — Mon, 27 Oct 2025 21:22:46 +0000

🧠 Day 12 — Smallest Missing Integer & Schedule-Driven Jobs ⚙️

🧩 DSA Problems [1 hr]

Problem: 2598. Smallest Missing Non-negative Integer After Operations

💡 Approach: Greedy

Intuition

Each number in the array can be shifted by multiples of value.
That means all numbers that share the same remainder when divided by value belong to the same transformable group.

Example:
If value = 3, then numbers 0, 3, 6, 9 can all become one another through these operations.

We want to maximize the MEX (minimum excluded non-negative integer).
To do this, we iterate from 0 upward and check if there’s still a number left in the corresponding remainder group (mex % value).
If yes → use one and move forward.
If no → we found our MEX.

💻 Code

class Solution:
    def findSmallestInteger(self, nums: List[int], value: int) -> int:
        mp = Counter(x % value for x in nums)
        mex = 0
        while mp[mex % value] > 0:
            mp[mex % value] -= 1
            mex += 1
        return mex

📊 Complexity

Metric	Complexity
⏱ Time	O(n)
💾 Space	O(value)

🧩 Key Learnings

Grouping by modular equivalence can simplify complex transformation logic.
Greedy strategies work beautifully when you can define a clear incremental choice.
“Remainders as buckets” is a powerful way to partition search spaces efficiently.

🏗 System Design — Roadmap.sh [1 hr]

⏰ Schedule-Driven Background Jobs

Not every task needs an event or user trigger — some just need to run on time.
That’s where schedule-driven jobs come in: systems that operate on timers, intervals, or cron schedules.

💡 What It Is

A schedule-driven job runs automatically based on time-based triggers such as:

Every minute/hour/day (cron, Celery Beat, Airflow DAGs, etc.)
At specific times (00:00 UTC daily backup)
After delays (run job after 5 minutes)

🧱 Common Examples

Type	Description
🧾 Batch Processing	Aggregate logs, update indexes, or recompute recommendations daily.
📊 Reports & Analytics	Generate daily KPIs or email summaries every morning.
🧹 Maintenance Tasks	Cleanup old data, archive inactive sessions, or delete expired tokens.
🧮 Consistency Checks	Verify data integrity or sync caches periodically.

⚙️ How It’s Done

Local Scheduler: OS-based (like cron jobs or Windows Task Scheduler).
App Scheduler: Framework-level (Celery Beat, Sidekiq Scheduler, or Quartz).
External Scheduler: Managed cloud services (AWS EventBridge, Azure Logic Apps, Google Cloud Scheduler).

⚠️ Design Considerations

Concern	Description
🧩 Idempotence	A job might run twice — make sure repeating it doesn’t cause data corruption.
🧍 Single Instance Execution	When your system scales, you must ensure only one instance of the job runs globally.
⏳ Overlapping Jobs	A job may still be running when the next scheduled run starts — use locks or queues to prevent overlap.

🔗 Great read: What Does Idempotent Mean? (Particular.net)

🧠 Reflection

This day connects two powerful ideas:

In DSA, you optimized resource use by smartly grouping operations.
In System Design, you optimized time and execution with predictable schedules.

Both require discipline, rhythm, and state awareness — hallmarks of scalable design, both in code and in life.

✅ Day 12 Summary:

Consistency breeds reliability — in arrays, systems, and habits.

Daily DSA and System Design Journal - 11

I.K — Sat, 25 Oct 2025 16:45:32 +0000

🧠 Day 11 — Adjacent Subarrays II & Event-Driven Systems 🚀

🧩 DSA Problems [1 hr]

Problem: 3350. Adjacent Increasing Subarrays Detection II

🧭 Intuition

This is the extension of the Day 10 problem — instead of checking if adjacent increasing subarrays exist, now we calculate the maximum possible value of k for which such adjacent increasing subarrays can exist.

To do that efficiently, you only need one traversal, keeping track of:

cnt — length of current increasing subarray
precnt — length of previous increasing subarray

Whenever the sequence breaks, you swap and reset counts, updating your ans as the max of:

min(precnt, cnt) — previous and current adjacent segments
cnt // 2 — when both subarrays are within one long increasing sequence

💻 Code

class Solution:
    def maxIncreasingSubarrays(self, nums: List[int]) -> int:
        n = len(nums)
        cnt, precnt, ans = 1, 0, 0
        for i in range(1, n):
            if nums[i] > nums[i - 1]:
                cnt += 1
            else:
                precnt, cnt = cnt, 1
            ans = max(ans, min(precnt, cnt))
            ans = max(ans, cnt // 2)
        return ans

🧩 Key Learnings

Reusing logic from simpler problems to solve harder variants is true problem-solving maturity.
Tracking previous states is often more efficient than recomputation.
Pattern recognition in algorithms mirrors event tracking in systems — both rely on state transitions.

🏗 System Design — Roadmap.sh [1 hr]

⚡ Event-Driven Architecture

Event-driven systems are designed around reactions to triggers, not continuous polling or synchronous requests. Instead of waiting for something to finish, the system responds when something happens.

💡 How It Works

Event Source: Something happens — user clicks “Place Order”, a file is uploaded, a payment is completed.
Event Message: The system emits an event (like “OrderPlaced”).
Event Queue or Broker: Middleware (like Kafka, RabbitMQ, or AWS SNS/SQS) transports the event asynchronously.
Event Consumers: Background workers or services listen for specific events and react accordingly — sending emails, updating databases, or triggering other workflows.

🧱 Common Patterns

Pattern	Description
📨 Message Queue	UI or another service puts an event into a queue. Workers listen and process them asynchronously.
💾 Change Data Capture (CDC)	Background job reacts to updates in storage or database tables.
🌐 Webhooks / API Calls	One service triggers another by making HTTP requests or publishing an event.

⚙️ Real-World Examples

🛒 E-commerce: “OrderPlaced” event triggers inventory update, payment capture, and confirmation email.
💬 Messaging apps: “MessageSent” event triggers push notifications to the receiver.
🧾 Finance systems: “TransactionProcessed” event triggers audit logs and downstream reconciliation.

🧩 Why Event-Driven Architectures Matter

Advantage	Description
⚡ Responsiveness	Systems react immediately when something happens.
🧭 Scalability	Different services can scale independently.
🔁 Loose Coupling	Services communicate through events, not direct dependencies.
🧰 Resilience	If one consumer fails, events stay in the queue until retried.

🧠 Reflection

Both today’s DSA and system design concepts highlight the power of state and sequence.

In arrays → detecting transitions (increasing → reset).
In systems → reacting to events (trigger → response).

Progress isn’t just about doing things — it’s about reacting better to change.

Daily DSA and System Design Journal - 10

I.K — Tue, 14 Oct 2025 12:30:13 +0000

"Small daily progress leads to massive long-term impact."

After 10 days of deliberate consistency (with one comeback arc), I’m starting to see deeper intuition forming — both in coding logic and in understanding scalable systems.

🧩 DSA Problems [1 hr]

Problem: 3349. Adjacent Increasing Subarrays Detection I

This one was subtly challenging — the logic feels simple at first glance, but optimizing for a single traversal takes thought.

💡 Approach: One-Time Traversal

🧠 Intuition

If two adjacent strictly increasing subarrays of length k exist, they also exist for all lengths < k.
So the key is to find the largest valid k′ and check if it satisfies the condition.

We track two variables:

cnt: length of the current increasing subarray
precnt: length of the previous one

At every point:

If nums[i] > nums[i−1], increment cnt.
Else, the increasing streak resets — set precnt = cnt, cnt = 1.

Then compute:

min(precnt, cnt) → represents adjacent subarrays.
cnt // 2 → represents one long continuous increasing run.

💻 Code

class Solution:
    def hasIncreasingSubarrays(self, nums: List[int], k: int) -> bool:
        n = len(nums)
        cnt, precnt, ans = 1, 0, 0
        for i in range(1, n):
            if nums[i] > nums[i - 1]:
                cnt += 1
            else:
                precnt, cnt = cnt, 1
            ans = max(ans, min(precnt, cnt))
            ans = max(ans, cnt // 2)
        return ans >= k

⚡ Takeaways

Built intuition around state tracking across traversals.
Reinforced understanding of adjacency logic and sequence continuity.
Learned to express a condition efficiently without nested loops.

🏗 System Design — Roadmap.sh [1 hr]

🎯 Topic: Background Jobs

Background jobs handle work that doesn’t need to block the main application flow. Think of them as quiet backstage workers keeping your system smooth.

🧠 Common Use Cases

✅ Maintenance tasks: cleanups, report generation, backups
✅ Heavy computation: ML training, analytics, or aggregation
✅ Async communication: emails, notifications, webhooks
✅ Batch data ops: imports/exports, ETL pipelines

⚙️ Implementation Patterns

Job Queue + Workers: Tasks get queued (e.g., RabbitMQ, SQS, Redis Queue), then processed by worker nodes.
Schedulers (e.g., Cron): Trigger recurring background tasks.
Retry + Monitoring: Failed jobs should retry intelligently with backoff and be observable (via dashboards/logs).

🧩 Real-World Examples

Gmail: sending emails asynchronously after user hits “Send”
Stripe: generating reports and invoices via background batch jobs
GitHub: background actions for CI/CD pipelines

💬 Reflection

The “background job” concept mirrors our own learning process:
the main thread is daily consistency, while the background jobs are reflection, documentation, and review — silently compounding over time.

✅ Key Takeaways

DSA sharpened my reasoning for adjacency-based problems.
System Design reinforced non-blocking execution and asynchronous scaling.
10 Days in — this rhythm is starting to feel automatic.

🤝 Let’s Connect

10 days in — what’s your “background job” for personal growth?
Something that runs quietly every day, but changes you over time?

Drop a ⚙️ if you’ve got one.

🧠 Day 9 — Back After 34 Days! Restarting My DSA + System Design Journey 🚀

I.K — Mon, 13 Oct 2025 19:47:23 +0000

After a 34-day drought, I’m officially back in the grind — and it feels good to get the rhythm going again. 💪

🧩 DSA Problems [1 hr]

Problem: Find Resultant Array After Removing Anagrams (LeetCode 2273)

This was a nice warm-up to shake off the rust — not too complex, but a solid logic-based question.

🧠 Idea

Iterate through the list, and only keep a word if its sorted characters differ from the previous one’s sorted characters (meaning it’s not an anagram).

💻 Code
class Solution(object):
def removeAnagrams(self, words):
ans = [words[0]]
for i in range(1, len(words)):
a, b = sorted(words[i]), sorted(ans[-1])
if a != b:
ans.append(words[i])
return ans

⚡ Takeaways

Used sorted strings to detect anagrams efficiently.

Perfect reminder that simplicity > cleverness — clean logic wins.

Great re-entry problem to rebuild problem-solving momentum.

🏗 System Design — Roadmap.sh [1 hr]
🌐 Topic: Availability in Numbers

Availability is all about how long a service stays up and running — usually expressed in number of 9s.

Level Uptime % Max Downtime Per Year
3 Nines 99.9 % 8 h 41 min 38 s
4 Nines 99.99 % 52 min 9.8 s

Even one extra “9” massively cuts downtime.

⚙️ Availability in Sequence vs Parallel

In Sequence

Availability drops because both components must work.

Total = A(Foo) × A(Bar)

Example: 99.9 % × 99.9 % = 99.8 %.

In Parallel

Availability rises since one component can cover for another.

Total = 1 – (1 – A(Foo)) × (1 – A(Bar))

Example: 99.9 % each ⇒ 99.9999 %.

You can experiment with numbers here → uptime.is calculator
.

🧩 Reflection

Coming back after a break reminded me that availability applies to humans too: when one part of your routine goes down, redundancy (habits, structure, accountability) helps bring it back up. 😉

💬 Final Thoughts

✅ Day 9 done!
It’s not about never falling off — it’s about coming back stronger.

Key takeaways:

Keep DSA problems light to rebuild momentum.

Revisit System Design numbers to solidify intuition.

Progress > Perfection — always.

🤝 Let’s Connect

Have you ever taken a break and struggled to restart your learning streak?
Drop a 🔁 if you’ve ever had to “replicate” your own discipline!

Daily DSA and System Design Journal - 8

I.K — Tue, 09 Sep 2025 22:50:45 +0000

🚀 Day 8: System Design + DSA Journey

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 8 — kicking off a brand new week! 💡

🏗 System Design: Replication

Today’s concept was Replication — an availability pattern where multiple copies of data are stored across locations to improve resilience and scalability.

There are two main types:

🧭 Master-Slave Replication

Master handles all writes (and sometimes reads).
Slaves handle reads only, reducing load on the master.
If the master fails, a slave can be promoted.
Often used to scale read-heavy workloads.

⚠️ Disadvantages:

Slave promotion adds complexity.
Replication lag can cause stale reads.
Heavy write loads can overwhelm replicas.

🔁 Master-Master Replication

Multiple masters handle both reads and writes.
Higher availability since any node can serve as fallback.
Useful when you need multi-region writes.

⚠️ Disadvantages:

Requires conflict resolution (e.g., two writes at once).
Can hurt performance due to synchronization overhead.
Often trades off consistency for availability.

💭 My Thoughts: Replication is one of those things that sounds simple (“just copy the data”), but the edge cases and trade-offs—lag, conflicts, and complexity—make it a real engineering challenge.

💻 DSA Challenge: 3Sum

Today’s LeetCode challenge was 15. 3Sum.

⏳ Time spent: ~1+ hours (with the help of this YouTube walkthrough).

👨‍💻 Code Snippet

class Solution:
    def threeSum(self, nums: List[int]) -> List[List[int]]:
        res = []
        nums.sort()

        for i in range(len(nums)):
            if i > 0 and nums[i] == nums[i-1]:
                continue

            j, k = i + 1, len(nums) - 1
            while j < k:
                total = nums[i] + nums[j] + nums[k]
                if total > 0:
                    k -= 1
                elif total < 0:
                    j += 1
                else:
                    res.append([nums[i], nums[j], nums[k]])
                    j += 1
                    while j < k and nums[j] == nums[j-1]:
                        j += 1
        return res

✨ Key Takeaways

Sorting + two-pointer technique = super efficient here.
Avoids brute-force O(n³) by reducing it to O(n²).
Learned how to skip duplicates to keep results clean.

🙌 Final Thoughts

Day 8 gave me a powerful reminder:

On the System Design side, replication is about balancing availability vs complexity.
On the DSA side, smart strategies like sorting + two pointers can completely transform performance.

I’m excited to keep this momentum rolling into the new week 🚀.

🤝 Let’s Connect!

💡 This is Day 8 — the start of Week 2!

I’d love to hear from you:

Have you worked with replication setups (master-slave or master-master)? Which challenges stood out?
Any alternative approaches you’ve used for the 3Sum problem?
Or just drop a 🔁 in the comments if you’ve ever had to replicate systems (or solve 3Sum 😉).

Your feedback, experiences, and encouragement push me to keep showing up daily — let’s make this journey even more interactive 🙏.

📅 Week 1 Recap: System Design + DSA Journey

I.K — Fri, 05 Sep 2025 21:30:45 +0000

Hello everyone! This week I began my daily learning journey — diving into System Design concepts (via the roadmap.sh System Design Roadmap) and solving DSA challenges on LeetCode.

✅ 7 days straight of showing up. Here are the highlights:

🏗 System Design Concepts Covered

Latency vs Throughput → Learned how speed (latency) and volume (throughput) trade off in system performance.
Consistency Patterns → Strong, Weak, and Eventual — and where each makes sense (finance vs gaming vs social media).
Availability Patterns → Redundancy, Replication, Load Balancing, Circuit Breakers, etc.
Failover → Active-passive vs active-active setups, and why resilience always adds complexity.

💡 Biggest Insight: System Design is about trade-offs, not absolutes. You never get high availability, high consistency, and high performance all at once.

💻 DSA Problems Tackled

Regular Expression Matching (hard) → Recursive approach stretched my thinking.
Integer ↔ Roman Conversions → Dictionary lookups + loops made the logic clean.
Longest Common Prefix → Sorting trick was an elegant win.

💡 Biggest Insight: For DSA, sometimes brute force teaches you the problem space — but the best solutions come from reframing (like sorting or recursion).

🏆 Week 1 Reflections

Showed up daily despite challenges (some problems took 2–3 hours).
Learned to balance deep dives (like regex recursion) with practical clarity (like Roman numeral conversions).
Seeing patterns emerge between System Design and DSA: both are about trade-offs and structured problem solving.

🚀 What’s Next (Week 2 Goals)

Push into more advanced system design topics (e.g., gRPC, DB sharding, caching strategies).
Continue solving medium/hard LeetCode problems, but improve on timeboxing solutions.
Start sharing shorter code insights to make posts even more practical for readers.

🤝 Let’s Connect!

That’s Week 1 in the books 🎉.

If you’ve been following along, I’d love to hear:

Which System Design trade-off do you find most challenging in real projects?
What’s your DSA strategy — brute force first or optimal-first thinking?
Or just drop a 💡 to celebrate learning and consistency!

Your engagement helps me keep momentum, and I’d love to make Week 2 even better — for me and for everyone reading 🚀.

Daily DSA and System Design Journal - 7

I.K — Fri, 05 Sep 2025 15:04:16 +0000

🚀 Day 7: System Design + DSA Journey

🏗 System Design: Failover

Today’s concept was Failover — an availability pattern that ensures a system can continue to function if a component fails.

At its core:

The primary component handles requests.
The secondary/backup component stays on standby.
If the primary fails, the backup kicks in — keeping the system alive with minimal disruption.

🔄 Types of Failover

💤 Active-Passive (Master-Slave)

Primary handles all traffic.
Backup sits idle, monitoring via heartbeats.
If the primary fails → backup takes over.
Can be hot standby (already running) or cold standby (needs startup).

⚡ Active-Active (Master-Master)

Both servers handle traffic concurrently.
Load is shared between them.
Public-facing: DNS must know about both IPs.
Internal-facing: application logic must route to both.

⚠️ Challenges with Failover

Extra hardware + complexity.
Risk of data loss if primary fails before replication completes.

💭 My Thoughts: Failover reminds me that resilience is never “free.” You gain uptime, but at the cost of added complexity, infra, and edge-case handling. Still, for critical systems, it’s worth it.

💻 DSA Challenge: Longest Common Prefix

Today’s DSA problem was 14. Longest Common Prefix.

⏳ Time spent: ~1 hour.
I started with a fixed-prefix-length approach (which worked but wasn’t optimal). After exploring more solutions, I found this sorted strings approach to be elegant and efficient.

👨‍💻 Code Snippet

class Solution:
    def longestCommonPrefix(self, v: List[str]) -> str:
        ans = ""
        v = sorted(v)
        first, last = v[0], v[-1]

        for i in range(min(len(first), len(last))):
            if first[i] != last[i]:
                return ans
            ans += first[i]
        return ans

✨ Key Takeaways

Sorting reduces the problem to comparing just the first and last strings.
Clean, efficient, and avoids unnecessary checks.
Sometimes a different perspective on the problem (like sorting) gives a more elegant solution than brute-force approaches.

🙌 Final Thoughts

Day 7 wraps up my first full week of this journey.

On the System Design side, Failover showed me how high availability is engineered through redundancy and switchover strategies.
On the DSA side, I learned that simplicity often emerges from smart problem framing (like sorting).

One week in, and I already feel sharper at identifying trade-offs and structuring solutions. 💪

🤝 Let’s Connect!

🎉 7 days straight — the first milestone achieved!

But here’s where I’d love your help:

What’s your experience with failover setups — active-passive vs active-active?
Do you prefer clever solutions like sorting for prefix problems, or do you stick with more direct approaches?
Or just drop a 🎯 in the comments to celebrate 1 full week!

Your engagement (likes, shares, comments) not only motivates me but also helps more learners see this journey. Let’s keep building together 🚀.