When you hit the system design stage of a Scala interview, the interviewer isn't just checking if you know how to draw boxes and arrows. They're looking to see if you can apply the philosophy of the language—immutability, type safety, and non-blocking concurrency—to the architecture itself. I've seen a lot of great coders stumble here because they treat system design as a separate, generic exercise, forgetting that the tools we use in Scala (like ZIO, Cats Effect, or Pekko) actually dictate how we should approach scalability.

Let's take a concrete example: designing a Real-Time Price Alert System. The requirement is simple: users follow a product, and as soon as the price drops below their threshold, they get a push notification. It sounds trivial, but this is where the gap between a "junior" design and a "senior" design becomes obvious.

The Polling Trap and Database Exhaustion

The naive way to build this is the "Cron-and-Query" approach. You'd probably suggest a scheduled job that runs every minute, queries the database for all active alerts, compares the current price to the user's threshold, and sends a notification if the condition is met. On paper, it works. In a small demo, it's actually faster to implement.

But here's where it breaks. As your user base grows to millions of alerts, that "simple" query becomes a monster. You're hitting the database every 60 seconds for data that likely hasn't changed for 99% of your users. You're wasting CPU cycles, locking rows, and creating massive spikes in database load. If you try to scale this by adding more polling workers, you aren't solving the problem; you're just DOSing your own database more efficiently. In an interview, if you suggest polling for a high-scale system, it's a red flag that you're thinking in synchronous, imperative terms rather than reactive ones.

Event-Driven Reactivity with Scala Streams

The better way is to invert the flow. Instead of the alert system asking the database "Is it time yet?", we make the price-update service tell the alert system "The price just changed."

I'd propose an event-driven architecture using a message broker like Kafka. Whenever a price changes, a PriceChanged event is published to a topic. Your Scala backend then consumes this stream using something like FS2 or Pekko Streams. Because Scala handles non-blocking I/O so well, a single instance of your service can handle thousands of concurrent events without choking on thread overhead.

case class PriceChanged(productId: UUID, newPrice: BigDecimal)
case class Alert(userId: UUID, productId: UUID, threshold: BigDecimal)

// Imagine a stream processing logic like this:
priceEventStream
  .mapAsync(10) { event => 
    alertRepository.findAlertsForProduct(event.productId)
      .filter(_.threshold >= event.newPrice)
  }
  .flatMap(alerts => alerts.toStream)
  .evalMap(alert => notificationService.send(alert))


Now, the system only does work when something actually happens. We've moved from a system that scales based on the number of users to one that scales based on the number of price changes. That is a massive architectural win.

The Trade-off: Consistency vs. Complexity
Now, if I'm your interviewer, I'm going to push back. I'll ask, "What happens if the Kafka consumer crashes? Do users miss their alerts?" This is where you show your maturity. You admit that the event-driven approach introduces eventual consistency. Unlike the polling method, where you have a guaranteed (albeit slow) check every minute, the event-driven system depends on the reliability of the message broker and the consumer's offset management.

I'd argue that for a price alert, eventual consistency is perfectly acceptable. A user getting a notification 2 seconds late is fine; a database crashing under the weight of a million SELECT statements is not. The "cost" here is the added operational complexity of managing Kafka and handling idempotent writes (ensuring you don't send the same alert twice if a consumer restarts), but the "gain" is a system that can scale linearly without killing your data layer.

📋 Practical Task

Exercise: Designing a Rate-Limited Notification Dispatcher

In our Price Alert System, we discovered that an event-driven approach is superior. However, there is a new problem: if a popular product's price fluctuates rapidly, we might accidentally send 50 notifications to a single user in one minute, which is a great way to get your app uninstalled.

Your Task: Write a system design proposal (in prose or a structured outline) for a "Notification Dispatcher" layer that sits between the Alert Logic and the actual Push Service. Your design must address the following:

• The Strategy: How will you track how many notifications a user has received in the last window of time? (Think about where this state lives—local memory, Redis, etc.).
• The Concurrency: How will you ensure that if two alerts for the same user hit the dispatcher at the exact same millisecond, you don't bypass the rate limit?
• The Scala Edge: Explain how you would use a specific Scala concurrency primitive (e.g., ZIO Ref, Akka Actor, or a specific FS2 operator) to handle this state safely.

Avoid a generic "I will use a database" answer. Focus on the trade-offs between latency and strictness.