> Markdown version of [/videos/100173-from-scheduler-to-events-rethinking-alerts-in-a-modular-system?t=958](https://www.wearedevelopers.com/videos/100173-from-scheduler-to-events-rethinking-alerts-in-a-modular-system?t=958). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# From Scheduler to Events: Rethinking Alerts in a Modular System

Are central schedulers choking your enterprise system? Learn how the European Central Bank inverted their data flow to eliminate 90% of unnecessary data loads without a heavy rewrite.

- **Speakers:** [Cristina Musceleanu](https://www.wearedevelopers.com/@cristina-musceleanu)
- **Event:** World Congress 2026 Europe
- **Published:** July 9, 2026
- **Duration:** 23:51
- **URL:** https://www.wearedevelopers.com/videos/100173-from-scheduler-to-events-rethinking-alerts-in-a-modular-system

## Summary

Many enterprise systems rely on central schedulers to process alerts, but as dependencies scale, this architecture often degrades into a performance bottleneck. In the European Central Bank's IMAS system, a scheduled notification engine that once handled a few entities grew to manage dozens, leading to memory bloat, high processing times, and severe blast radius issues. Minor changes triggered catastrophic email storms, and "polling the past" caused transient alerts to be missed entirely before the next polling cycle even began.

Rather than pursuing a heavy rewrite using Kafka or Change Data Capture (CDC) immediately, the team isolated the core architectural flaw: loading all database entities prior to evaluating rules. By inverting the flow to start with business rules, checking for state changes, and only then fetching required data, they eliminated 90% of unnecessary data loads. This modular migration adhered to a defining design principle: "Keep the core stable. Make the edges replaceable."

Separating triggers from core rule evaluation ensures that future event mechanisms can be swapped seamlessly without rewriting the entire notification engine. This journey highlights that architecture is a team sport defined by setting clear boundaries rather than merely writing code. By treating observability as a baseline and choosing simple, step-by-step implementations, teams can build for future flexibility. Ultimately, "great architecture makes change boring," transforming stressful deployments into reliable, shared enterprise capabilities.

**Keywords:** enterprise architecture modernization, event-driven processing, scheduler-based notification engines, system scalability challenges, decoupling alert logic, legacy system refactoring, modular architecture design, kafka event integration, change data capture, database polling limitations, decoupled trigger mechanisms, blast radius mitigation, business rule evaluation, building observable systems, transient alert processing

## Chapters

1. **Origin and evolution of an enterprise notification engine** (00:12) — Starting with a simple polling scheduler delivers quick business value but outgrows its straightforward design as system usage expands.
1. **Adding complexity to a centralized scheduling architecture** (03:42) — Shoehorning new entity dependencies into a rigid polling structure compounds technical debt as business requests multiply.
1. **Identifying symptoms of a strained notification architecture** (07:46) — Polling an entire database continuously exposes scaling limits like memory spikes, massive blast radius impacts, and missed transient alerts.
1. **Reversing data loading processes to optimize alert evaluation** (10:53) — Evaluating business rules before fetching database states significantly reduces unnecessary data retrieval and lowers critical processing times.
1. **Decoupling business logic to create replaceable architectural edges** (13:05) — Isolating core rules from the scheduler trigger enables the system to safely adopt downstream event-driven streaming pipelines when ready.
1. **Guiding principles for sustainable and scalable software modernizations** (15:58) — Establishing clear module boundaries and observable states transforms highly stressful architectural refactors into completely predictable platform deployments.
1. **Audience questions on implementation timelines and alert logic** (20:07) — Explaining execution timelines and clarifying how resolving open and close rule evaluations fixes transient notification failures immediately.

## Related Moments

- [Strategies for modernizing and mitigating legacy system risks](https://www.wearedevelopers.com/videos/100215-smart-test-automation-the-experience-of-legacy-transformation) (from "SMART Test Automation - the experience of legacy transformation")
- [Scaling software concepts to system architecture](https://www.wearedevelopers.com/videos/121-rethinking-reactive-architectures-with-graphql) (from "Rethinking Reactive Architectures with GraphQL ")
- [Introducing beneficial architectural patterns like event sourcing](https://www.wearedevelopers.com/videos/218-seven-myths-three-reasons-one-goal) (from "Seven Myths, Three Reasons, One Goal")
- [Complexity tradeoffs in event-driven legacy architecture replacements](https://www.wearedevelopers.com/videos/1234-exploring-durable-execution-with-python) (from "Exploring Durable Execution with Python")
- [Introducing data management and the shift to streaming](https://www.wearedevelopers.com/videos/538-event-messaging-and-streaming-with-apache-pulsar) (from "Event Messaging and Streaming with Apache Pulsar")
- [Recognizing architectural drivers pushing event streaming system adoption](https://www.wearedevelopers.com/videos/538-event-messaging-and-streaming-with-apache-pulsar) (from "Event Messaging and Streaming with Apache Pulsar")

## Related Articles

- [Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)](https://www.wearedevelopers.com/magazine/745-why-event-driven-architecture-isn-t-about-speed-and-when-you-actually-need-it)
- [Now is the time for industrialized software development](https://www.wearedevelopers.com/magazine/601-now-is-the-time-for-industrialized-software-development)
- [How to Avoid Over-Engineering](https://www.wearedevelopers.com/magazine/546-how-to-avoid-over-engineering)
- [Navigating the AI Shift](https://www.wearedevelopers.com/magazine/629-navigating-the-ai-shift)

## Related Jobs

- [Senior Cloud Software Architect (all genders welcome) for our Intelligent Service Operations Hub](https://www.wearedevelopers.com/jobs/ext/1693682-senior-cloud-software-architect-all-genders-welcome-for-our-intelligent-service-operations-hub) at **Rosenxt Group**
- [Tribe Lead - ( Software) Engineering Centre of Excllence](https://www.wearedevelopers.com/jobs/ext/1475530-tribe-lead-software-engineering-centre-of-excllence) at **SD Worx**
- [Senior Cloud Software Architect (all genders welcome) for our Intelligent Service Operations Hub](https://www.wearedevelopers.com/jobs/ext/1284556-senior-cloud-software-architect-all-genders-welcome-for-our-intelligent-service-operations-hub) at **Rosenxt Group**
- [Senior Engineer, Infrastructure Platform](https://www.wearedevelopers.com/jobs/ext/328836-senior-engineer-infrastructure-platform) at **Intercom, Inc.**
- [Senior Cloud Native Solution Architect (all genders welcome) - Kubernetes, CNCF, MlOps](https://www.wearedevelopers.com/jobs/ext/101488-senior-cloud-native-solution-architect-all-genders-welcome-kubernetes-cncf-mlops) at **Rosenxt Group**
- [Platform Engineer - Mercury Runtime Platform](https://www.wearedevelopers.com/jobs/ext/293235-platform-engineer-mercury-runtime-platform) at **Raiffeisen Bank International AG**