Functional and Non Functional Requirements

Architecture starts before diagrams. If you cannot explain what the system must do and what it must survive, you are not designing yet. You are guessing.

Imagine Amazon. A customer places an order. The system may need to send an order confirmation to the customer, payment success confirmation, invoice email, warehouse task, seller notification, courier update, and internal fraud alert. Calling all of these "send email" hides the real design.

Functional Requirements

Functional requirements describe behavior the system must provide.

When customer places order:
  - create customer confirmation
  - send payment success receipt
  - create invoice notification
  - notify warehouse team
  - notify seller if marketplace order
  - notify courier when package is ready

Each requirement has a receiver, channel, trigger, template, and success condition.

Example:

Requirement: Send order confirmation
Trigger: OrderPlaced
Receiver: Customer
Channels: Email + Push
Template: order-confirmation-v3
Success: At least one customer-facing channel accepted by provider

This is clearer than "send email." It gives engineering, product, and operations the same contract.

Non Functional Requirements

Non-functional requirements describe quality and limits.

Term          Meaning                              Notification Example
Latency       Time from event to delivery attempt  Push within 3 seconds
Throughput    Work handled per unit time           100,000 jobs/minute
Availability  System remains usable                API 99.9 percent uptime
Durability    Data survives failure                No queued job lost
Reliability   System behaves consistently          Retries transient failures
Idempotency   Repeated requests do not duplicate   Same order email sent once

SLA and SLO

An SLA is a promise to a customer or business. An SLO is an internal target used to meet that promise.

SLA: 99.9 percent of security notifications are accepted within 30 seconds.
SLO: 99.95 percent of security jobs leave the internal queue within 10 seconds.

The SLO is stricter because provider delays, network issues, and retries consume the remaining budget.

Delivery Guarantees

At-most-once means the system may drop a notification but will not duplicate it. This is acceptable for low-value marketing messages.

At-least-once means the system will retry until delivery is accepted, but duplicates are possible unless idempotency is enforced. This is common for transactional messages.

Exactly-once is the dream. In distributed systems it usually means "effectively once" through idempotency keys, unique constraints, and provider message IDs.

CREATE UNIQUE INDEX notification_dedupe_idx
ON notifications (event_id, user_id, channel);

This index makes repeated processing safer. If the OrderPlaced event is consumed twice, the database prevents duplicate rows for the same user and channel.

Constraints

Constraints shape design. A startup may choose BullMQ and PostgreSQL because it is operationally simple. A large marketplace may need Kafka, partitioning, provider failover, and regional workers. Both can be correct.

Common constraints:

1. Provider rate limits.
2. SMS cost limits.
3. Data retention rules.
4. Regional compliance.
5. Queue technology already used by the company.
6. Product requirement for real-time updates.

Production Requirement Template

Feature: Payment success notification
Trigger: PaymentSuccess event
Receivers: customer, finance audit stream
Channels: email, in-app
Latency target: email accepted within 60 seconds
Durability: no accepted event can be lost
Retry policy: 5 retries with exponential backoff
Duplicate policy: idempotency by payment_id + channel
Audit: store provider response and final status

This kind of requirement is directly convertible into schema, queue, worker, and monitoring work.

Common Mistakes

1. Designing architecture before defining latency and throughput.
2. Using SMS for everything because it feels urgent.
3. Forgetting idempotency until duplicate messages reach users.
4. Treating provider acceptance as user delivery.
5. Not separating marketing, transactional, and security requirements.

Interview Questions

1. How would you define requirements for an OTP notification?
2. What is the difference between SLA and SLO?
3. Why is idempotency critical in an at-least-once system?
4. Which notifications can safely use at-most-once delivery?

Exercise

Write a requirement template for "password changed" notification. Include trigger, receiver, channel, latency, retry policy, and duplicate policy.