Daily DSA and System Design Journal – 11

Avatar photoByAdil

🧠 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:

  1. min(precnt, cnt) — previous and current adjacent segments
  2. 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

  1. Event Source: Something happens — user clicks “Place Order”, a file is uploaded, a payment is completed.
  2. Event Message: The system emits an event (like “OrderPlaced”).
  3. Event Queue or Broker: Middleware (like Kafka, RabbitMQ, or AWS SNS/SQS) transports the event asynchronously.
  4. 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.

Similar Posts