Non-Functional Requirements Deep Dive

Non-functional requirements (NFRs) often drive more architectural decisions than functional ones. Security, compliance, residency, and observability shape where data lives, who can access it, and whether you can debug an outage at 3 a.m. Senior engineers treat NFRs as first-class constraints in the first five minutes of an interview—not as a "phase two" footnote.

If you can draw a clean API diagram but forget GDPR deletion paths or log redaction, this guide closes that gap. By the end, you should segment auth by risk, design for compliance from the data model up, and justify multi-AZ vs multi-region with requirements—not habit.

Related reading: For scale-side trade-offs once NFRs are clear, see Trade-offs at Scale. For how to say constraints aloud in the room, read Communication & Interview Strategy. For resilience when regions fail, continue to Failure-First Design Thinking.

Security, residency, and observability pull in different directions—the comparison matrix shows how senior engineers segment by risk instead of picking one pole.

---

Security Trade-offs: Auth vs UX

The Tension

Strong security often hurts UX:

• MFA adds friction
• Session timeouts force re-login
• Rate limiting blocks legitimate users
• Strict password rules frustrate users

Smooth UX can weaken security:

• "Remember me" extends session risk
• Social login reduces control
• Fewer auth steps = easier for attackers
• Password-less can have different attack surface

Senior Approach

1. Segment by risk: High-value actions (payments, settings) need stronger auth. Low-risk (browsing) can be lighter.
2. Progressive auth: Require step-up (MFA, re-auth) for sensitive operations.
3. Context-aware: Require re-auth for new device, new location, or after long idle.
4. Quantify the trade-off: "MFA reduces account takeover by X% but adds Y seconds. For payments, we accept Y. For feed view, we don't."

Example: Banking App

• Login: MFA required. UX cost accepted for security.
• View balance: Session token OK. Low risk.
• Transfer money: Re-auth or step-up MFA. High risk.
• Change password: Full re-auth. Critical.

Interview Tip

"When we have auth vs UX trade-off, I segment by risk. For [sensitive operation], we'd require [stronger auth]. For [low-risk operation], session token is fine. I'd also consider step-up auth—only prompt when risk increases."

---

Compliance-Driven Design: PII, GDPR, SOC2

PII (Personally Identifiable Information)

What it is: Data that identifies a person (name, email, phone, IP, etc.)

Design implications:

• Encryption at rest and in transit: Default for PII
• Access control: Who can read/write? Audit logs.
• Retention: How long do we keep it? Deletion policy?
• Minimization: Collect only what we need
• Purpose limitation: Use only for stated purpose

GDPR

Key requirements:

• Right to access: User can request their data
• Right to deletion: "Right to be forgotten"
• Data portability: Export in machine-readable format
• Consent: Explicit consent for processing
• Data residency: EU data in EU (for some interpretations)

Design implications:

• User ID as key: Need to find and delete all user data
• Soft delete first: Hard delete after retention
• Export pipeline: Generate and deliver user data export
• Consent tracking: Store what user consented to, when
• Data map: Know where PII lives (DBs, logs, backups)

SOC2

Focus: Security, availability, confidentiality, processing integrity, privacy.

Design implications:

• Access logging: Who accessed what, when
• Change management: Audit trail for config and code changes
• Incident response: Documented process, runbooks
• Encryption: Standard for sensitive data
• Redundancy: Availability requirements

Senior Insight

"Compliance isn't a feature you add later. It shapes data model (can we delete by user?), storage (where does data live?), and access (who can see what?). Design for it from the start or pay for retrofits."

---

Multi-Region vs Multi-AZ Decisions

Multi-AZ (Same Region)

What it is: Deploy across multiple availability zones in one region (e.g., us-east-1a, us-east-1b).

Pros:

• Protects against AZ failure
• Lower latency (same region)
• Simpler than multi-region
• Often sufficient for most apps

Cons:

• Region outage = full outage
• Data residency: all in one region
• Latency: distant users still far

When to use: Default for production. Protects against AZ failure, not region failure.

Multi-Region

What it is: Deploy in multiple regions (e.g., us-east, eu-west, ap-south).

Pros:

• Region failure = failover to another
• Lower latency for global users (serve from nearest)
• Data residency (EU data in EU)
• Compliance (some regulations require it)

Cons:

• Complex: replication, conflict resolution, failover
• Cost: 2–3x infra
• Data consistency across regions is hard
• Operational burden

When to use:

• Global user base with latency requirements
• Compliance (data residency)
• Region-level redundancy requirement
• Business continuity for region outage

Decision Framework

Requirement	Multi-AZ	Multi-Region
AZ failure protection	✓	✓
Region failure protection		✓
Global low latency		✓
EU data in EU		✓
Simplicity	✓
Cost	Lower	2–3x

Senior Interview Move

"I'd start with multi-AZ for redundancy. If we have global users and need low latency, or if we have EU users and need data residency, I'd add multi-region. Multi-region adds complexity—replication, failover, consistency—so I'd only do it when the requirement justifies it."

---

Observability as Part of Design

The Three Pillars

• Logs: Discrete events. "User X did Y at Z." Debugging, audit.
• Metrics: Aggregated numbers. Request rate, error rate, latency p99. Dashboards, alerting.
• Traces: Request flow across services. "This request hit A, then B, then C." Distributed debugging.

Design Implications

Logs:

• Structured format (JSON). Include request ID, user ID, timestamp.
• Log levels: debug, info, warn, error.
• PII: Redact or hash in logs. GDPR consideration.
• Retention: How long? Cost and compliance.
• Centralized: Ship to CloudWatch, Datadog, etc.

Metrics:

• Key metrics: latency (p50, p99), throughput (RPS), error rate.
• Business metrics: signups, conversions, revenue.
• Export: Prometheus, StatsD, or cloud native.
• Dashboards: Pre-define what we need to see.

Traces:

• Trace ID propagated across services.
• Span per service/DB call. Parent-child relationship.
• Sampling at scale (can't trace every request).
• Tools: Jaeger, Zipkin, X-Ray, Datadog APM.

Senior Approach

"Observability isn't bolted on. We need: (1) Request IDs for tracing, (2) Structured logs with context, (3) Key metrics (latency, errors, throughput) from day one, (4) Dashboards for operational visibility. I'd design the logging and tracing format into the service interfaces."

---

Compliance Failure Stories

Example: Unplanned Data Deletion

A company had user data spread across 50+ services and tables. GDPR deletion request. No single "delete user" path. Manual process took weeks. Lesson: Design for deletion. User ID as partition key. Cascade or job to purge.

Example: Logs Containing PII

A company logged full request bodies for debugging. Request bodies contained passwords, tokens, SSN. SOC2 audit found it. Costly remediation: purge logs, fix logging, retrain. Lesson: Never log PII. Redact by default.

Example: Single Region, Region Outage

A company had multi-AZ but single region (us-east). AWS us-east outage. Full downtime for hours. Lesson: For critical systems, multi-region may be worth the complexity. Evaluate based on business impact.

---

Thinking Aloud Like a Senior Engineer

Problem: "Design a system that stores user health data. HIPAA implied."

My first thought: Compliance drives the design. HIPAA = encryption, access control, audit logs, BAA with vendors.

Data model: User health data. PII + PHI. Encrypt at rest (KMS). Encrypt in transit (TLS). Access control: only authorised roles. Audit: who accessed what, when. Retention: HIPAA has rules. Deletion: user can request; we must purge.

Infra: HIPAA-eligible services (AWS has a list). No logging PII/PHI. Logs to isolated, access-controlled store.

Multi-region?: Depends. If US-only, single region + multi-AZ may suffice. If global, data residency matters. EU health data = different rules. I'd clarify: US only or global?

Observability: Metrics (latency, errors) without PII. Traces with trace ID, no PHI in span names. Logs redacted.

---

Summary

Non-functional requirements are not polish—they are structural. Security vs UX resolves through risk segmentation and step-up auth; compliance shapes encryption, deletion, audit, and residency from the data model; multi-AZ is the default resilience pattern while multi-region earns its cost only for global latency or legal residency; and observability (logs, metrics, traces) belongs in service interfaces from day one with PII redacted by default.

Key Takeaways

• NFRs before boxes — Ask about GDPR, PCI, HIPAA, and data residency in the first clarifying pass; they change storage geography and access patterns.
• Segment auth by risk — MFA on payments and settings; session tokens on low-risk reads; step-up when device, location, or action sensitivity changes.
• Compliance is a data-model problem — User ID as key, soft delete, export pipeline, consent store, and a data map beat retrofitting deletion across 50 services.
• Multi-AZ is the default — Same-region AZ redundancy handles most production outages; multi-region adds replication, failover, and consistency cost.
• Observability is designed in — Request IDs, structured logs, golden metrics (latency, errors, throughput), and trace propagation are part of the API contract.
• Never log PII by default — Full request-body logging fails audits and creates breach surface; redact at ingestion.
• Quantify security vs UX — "MFA adds Y seconds but cuts account takeover by X%" shows engineering judgment, not preference.

Apply This Thinking

Practice NFR-driven design on InterviewCrafted:

• Design Uber — Geo data, PII, and multi-region latency for a global user base.
• Design Twitter — Public vs private data, retention, and observability at high request volume.
• Design Amazon — PCI-adjacent checkout paths, audit trails, and availability targets.
• Cost-Aware Architecture — Multi-region and full observability stacks have real cost trade-offs.
• Monitoring & Observability — Topic depth on metrics, logs, and tracing after you place them in your HLD.

Related Topics

• Trade-offs at Scale — consistency, latency, and amplification once NFR boundaries are set.
• Failure-First Design Thinking — region and AZ failure modes when resilience NFRs bite.
• Cost-Aware Architecture — when multi-region and heavy observability justify their bill.
• SSL Certificate Expiry — operational NFR failure when renewal is treated as someone else's job.
• DNS Propagation Mistake — infra changes without observability and rollback planning.

FAQs

Q: How do I bring up compliance in an interview?

A: "Are there compliance requirements—GDPR, SOC2, HIPAA? That would affect data residency, encryption, and retention." Or assume: "I'll assume we need to handle PII responsibly—encryption, access control, deletion path."

Q: When is multi-region worth the cost?

A: When you have: global users with latency needs, data residency requirements, or business continuity needs that justify 2–3x infra cost and operational complexity.

Q: What's the most common NFR mistake?

A: Treating observability as an afterthought. You can't debug or operate what you can't see. Design logs, metrics, and traces into the architecture from the start.

Q: How are NFRs different from functional requirements in system design?

A: Functional requirements describe what the system does (post a photo, send a notification). NFRs describe how well and how safely—latency, availability, security, compliance, and operability. NFRs often eliminate whole architecture families before you pick a database.

Q: How do I balance security and UX without weakening both?

A: Use progressive and context-aware auth: lighter friction on read-only paths, step-up MFA on money movement or credential changes, and rate limits tuned per endpoint risk—not one global policy.

Q: What should I say about GDPR in a 45-minute interview?

A: Mention encryption, access control, user-initiated export and deletion paths, consent tracking, and knowing where PII lives (including logs and backups). You do not need a legal treatise—show the architectural hooks.

Q: Multi-AZ vs multi-region—what is the one-line default?

A: Multi-AZ within one region for HA against AZ failure; add multi-region only when users are global, latency to distant regions matters, or regulations require data residency.

Q: How does observability differ from monitoring in an interview answer?

A: Monitoring is alerting on known golden signals. Observability is designing the system so you can ask new questions during incidents—correlation IDs, structured logs, traces across services, and sampling strategy at scale.