Architecture Design Principles Questions

Fundamental architectural principles that guide design choices across systems: separation of concerns, loose coupling, modularity, encapsulation, resilience, observability, security by design, scalability by design, and maintainability. This topic evaluates a candidate's ability to apply these core principles, recognize anti patterns, and choose appropriate patterns based on constraints and non functional requirements.

MediumSystem Design

74 practiced

You are tasked with migrating a monolith to microservices using the strangler pattern. Describe the concrete steps you would take, how you would select the first service to extract, and strategies to migrate data with minimal user-visible downtime.

Sample Answer

Requirements & constraints:- Preserve existing functionality with minimal user-visible downtime- Incremental rollout, ability to rollback, observability, security, and operational readiness- Support team capacity and business priorities (high ROI features first)

High-level approach (strangler pattern):1. Instrument & observe: add tracing, metrics, feature flags, and API gateway in front of the monolith.2. Identify bounded contexts / domain seams via domain-driven design and telemetry (hot paths, change rate).3. Extract incrementally: create façade routes in the gateway that can route to either monolith or new service via feature flags.4. Deploy new service alongside monolith, run in parallel, shift traffic progressively.5. Decommission monolith endpoints as features stabilize.

Selecting first service to extract:- Choose a service with: clear bounded domain, well-defined API surface, low cross-cutting dependencies, high business value (reduces risk or cost), small team ownership, and limited data coupling.- Example: an authentication or billing domain—high value, isolated logic, measurable KPIs, easy to test.

Data migration strategies (minimal user-visible downtime):- Dual-write: For writes, have the application (or gateway) write to both monolith DB and new service DB during migration window.- Read-routing / fallback: New service reads from its DB; if missing, read-through from monolith and populate cache/DB (read-through migration).- Change data capture (CDC): Use CDC (Debezium/Kafka) to stream changes from monolith DB into new service DB for eventual consistency.- Schema versioning & compatibility: Use additive migrations, backward-compatible schema, and translator layer for transformations.- Cutover: Gradual traffic shift with feature flags, health checks, canary releases, and synthetic transactions. After sufficient time and verification, stop writing to monolith and decommission data owners.

Operational considerations & trade-offs:- Consistency: CDC + eventual consistency reduces downtime but requires handling reconciliation and idempotency.- Complexity vs risk: Dual-write is simpler to validate but incurs write amplification and risk of divergence—use reconciliation jobs.- Rollback plan: Keep gateway toggles and ability to route back to monolith; maintain monitoring and automated alerts.- Security & compliance: Ensure data residency and access controls during dual-write/CDC.

Outcome metrics:- Define success: latency, error rate, data divergence rate, feature flag percentage, and time-to-rollback. Use these to decide readiness to decommission monolith endpoints.

EasyTechnical

59 practiced

Describe what resilience means for a distributed application. List three resilience patterns (e.g., retries with backoff, circuit breaker, bulkhead) and give a one-sentence description of when each should be applied.

MediumTechnical

63 practiced

Define a logging and data retention policy for a customer-facing service that must comply with GDPR and also maintain forensic logs for 90 days. Include retention durations, PII handling, anonymization, and mechanisms for legal hold or audit requests.

Sample Answer

Requirements clarification:- Forensic logs retained 90 days.- GDPR: personal data minimization, lawful basis, rights to access/erasure, security, auditability.- Support legal hold / audit requests that may extend retention.

Proposed logging & retention policy (solutions-architect level):

1. Retention durations- Raw forensic logs (full, including PII where necessary for investigation): 90 days.- Aggregated/metric logs (no PII): 365 days.- Long-term anonymized telemetry (statistical trends): 3+ years.

2. PII handling & minimization- Log only fields required for operation/forensics. Define an allowlist per service (e.g., userID hash, request-id, timestamp, IP truncated).- Avoid logging sensitive PII (full name, payment data, unmasked email) unless a justified use case exists and approved by DPO.- Where identifiers are required, store pseudonymous identifiers (HMAC-SHA256(user_id, service_salt)) rather than raw identifiers.

3. Anonymization & pseudonymization- Pseudonymize at ingestion for production logs: replace raw identifiers with salted HMACs; store mapping (re-identification table) in a separate, access-controlled vault for authorized investigators only.- For anonymized datasets, apply irreversible techniques (tokenization + salt discarding or differential privacy where appropriate) so GDPR “personal data” no longer applies.

4. Security & storage- Encrypt logs at rest (KMS) and in transit (TLS).- Store short-term forensic logs on immutable, append-only storage configured with WORM/retention policies.- Strict RBAC: only specific roles (SRE+forensics) can access raw logs; access requires justification and is logged.

5. Legal hold / audit mechanism- Provide a legal-hold API: when triggered by Legal or DPO, the retention TTL of affected log objects is extended and a hold flag applied. Holds are tracked in an auditable registry (who, why, duration).- Re-identification mapping retrieval requires multi-party approval (e.g., DPO + Security lead) and is logged.

6. Deletion & proof- Automated deletion job enforces TTL; deletion events emit signed deletion receipts stored in audit ledger for compliance.- For records removed under erasure requests, remove or irreversibly anonymize both logs and mapping entries; if legal hold exists, notify requester of hold and follow lawful basis.

7. Monitoring, auditing & governance- Continuous monitoring of access, retention compliance, and failed deletions; weekly reports to DPO.- Annual DPIA and retention policy review; retention exceptions require documented justification and expiration.- Maintain searchable audit trail (who accessed which logs, re-identification events, holds, deletions).

Edge cases & trade-offs- Need balance: more PII in logs aids investigations but raises GDPR risk — prefer pseudonymization + re-identification vault.- For cross-border storage, ensure data residency and SCCs/adequate safeguards.

This design meets the 90-day forensic requirement while minimizing GDPR exposure via pseudonymization, strict access controls, auditable legal-hold procedures, and automated retention enforcement.

HardTechnical

68 practiced

Create a threat model for a new public REST API that allows third-party integrations. Identify high-value assets, likely threat vectors (e.g., API key leakage, injection, mass scraping), and list mitigations including rate limiting, auth scopes, WAF rules, and monitoring you would implement.

Sample Answer

Requirements & scope: public REST API for third-party integrations, multi-tenant, supports sensitive customer data and actions (read/write), issues API keys/secrets.

High-value assets- Customer PII and business data returned by APIs- OAuth tokens / API keys / client secrets- Privileged actions (billing, config changes)- Service availability and reputation- Rate-limiting/quota controls and usage metrics

Likely threat vectors- API key leakage (client-side exposure, git, logs)- Broken auth/authorization (excessive privileges, horizontal privilege escalation)- Injection (SQL/NoSQL, command) via input fields- Mass scraping / credential stuffing / brute force- Abuse of endpoints causing DoS or resource exhaustion- Man-in-the-middle on integrations without TLS- Business logic abuse (workflow manipulation)- Supply-chain (compromised third-party SDKs)

Mitigations (design + controls)- Auth & authZ - Use OAuth 2.0 + short-lived access tokens + refresh tokens; rotate and revoke - Fine-grained scopes and least-privilege API keys per integration - Per-tenant and per-client role-based access checks; resource-based authorization - Mutual TLS (mTLS) for high-value partners- Secrets handling - Issue client secrets once; encourage use of JWTs and PKCE for public clients - Secrets never logged; mask in telemetry; scan repos and CI for leaked keys- Rate limiting & quotas - Multi-level limits: global, per-client, per-tenant, per-endpoint - Burstable token-bucket with strict sustained limits; adaptive limits on anomalies - Enforce quota billing thresholds and automated throttling- Input validation & WAF - Parameterized queries/ORMs; input sanitization; reject unexpected content-types - WAF rules for OWASP Top 10, SQLi, XSS, path traversal; custom rules for known abuse - API gateway validate schema (OpenAPI) and reject malformed payloads early- Monitoring, detection & response - Centralized logs (structured, redacted) + SIEM; ingest API access, auth failures, error spikes - Anomaly detection: unusual rate per API key, geo anomalies, sudden scope use - Alerts + automated actions: temporary key suspension, IP throttling, challenge (CAPTCHA) - Retention for forensics; integrate with incident playbooks- Observability & telemetry - Per-request tracing, metrics (latency, error rate), usage dashboards - Audit trails for data access and admin actions; signed audit logs for compliance- Secure deployment & runtime - TLS 1.2+/HSTS, CSP for any developer portal, CORS restrictive by default - Least-privilege service accounts, secrets in vaults, dependency scanning, runtime WAF- Anti-scraping / bot defenses - Behavioral fingerprinting, progressive challenges, device reputation, IP reputation lists - Require signed requests (HMAC) for high-value endpoints- Testing & governance - Threat modeling during design, periodic red-teaming and fuzzing, SCA and pen tests - SLA and abuse policy, clear developer onboarding with security guidance

Trade-offs & justification- Strict limits and mTLS increase security but add integration friction; mitigate with tiered partner onboarding.- WAF + gateway validation reduces attack surface but must be tuned to avoid false positives; invest in monitoring and feedback loop.

Incident playbook highlights- Revoke compromised keys, throttle traffic, engage partner, rotate secrets, run forensic analysis, notify affected customers per policy.

EasyTechnical

66 practiced

Compare modularity and encapsulation in the context of service design. Provide an example where a service exposes an interface to hide implementation details, and explain how encapsulation improves maintainability while modularity aids scalability.

Unlock Full Question Bank

Get access to hundreds of Architecture Design Principles interview questions and detailed answers.

Join thousands of developers preparing for their dream job.