Katkat
Back

Design a CI/CD release notification service

AtlassianSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSoftware Engineering Fundamentals

Last updated

This problem evaluates your ability to design a flexible, object-oriented notification service that handles varying event triggers and subscriber preferences in a release pipeline.

Problem Statement

Design a backend notification service that alerts relevant stakeholders (e.g., developers, QA, SREs) whenever a CI/CD release pipeline transitions through different states (e.g., STARTED, TESTING_FAILED, DEPLOYED, ROLLBACK).

Your design must account for:

  1. Event Diversity: Different pipelines may trigger notifications differently (Slack, Email, PagerDuty).
  2. Subscription Management: Users should be able to subscribe to specific events based on project, environment, or severity levels.
  3. Idempotency: Ensure a user does not receive the same notification multiple times if a deployment stage is re-triggered due to network instability.

Requirements

  • Define a core class structure to handle ReleaseEvent objects.
  • Implement a mechanism to filter events based on subscriber rules.
  • Handle asynchronous notification dispatching.

Example Scenario

  • Input Event: { 'release_id': 'v1.2.3', 'project': 'backend-api', 'status': 'DEPLOYED', 'timestamp': 1672531200 }
  • Rule: 'Notify if status is DEPLOYED for project backend-api'.
  • Output: Dispatch message to configured channels (e.g., Slack channel #backend-releases).

Constraints

  • Assume a high volume of events during peak release hours.
  • The system must be extensible to new notification channels (e.g., Microsoft Teams, SMS) without modifying core business logic.

Implementation Task

Provide a high-level class design (using Python-style pseudocode) that demonstrates the Observer or Strategy pattern to satisfy these requirements.

Hints

Hint 1

Use the Strategy pattern to encapsulate different delivery mechanisms (Slack, Email, etc.) behind a common interface.

Hint 2

Implement an Event Bus or Message Queue to decouple the event ingestion from the notification dispatch logic to ensure system scalability.

Hint 3

To handle idempotency, include a unique event-id and a distributed cache (like Redis) to track successfully processed event IDs.

Follow-up questions

  • How would you handle a scenario where a third-party notification service (e.g., Slack API) is experiencing high latency or downtime?
  • If the business requires that developers only receive notifications during their working hours based on their timezone, where would you implement this logic?
  • How would you test this system to ensure that notifications are sent exactly once?