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.

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

Example:

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.

SLA and SLO

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

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

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.