The Question

AI-Powered Mortgage Agent App

Design an AI-powered mortgage agent application that guides users through the home loan process. The system should automate document collection and eligibility assessment, integrate with multiple lenders to compare rates, and provide personalized recommendations while complying with financial regulations.

PostgreSQL

Redis

SQS

Rate Limiting

Design Breakdown

Functional Requirements

Borrower Portal: Users can create profiles, submit mortgage applications, and upload required financial documents (paystubs, tax returns).

Agent Dashboard: Agents can view a pipeline of leads, review submitted documents, and update application statuses (e.g., Pending, Approved, Rejected).

Document Management: Secure upload, storage, and retrieval of sensitive PDF/Image files.

Communication: Automated email/push notifications for status changes.

Status Tracking: Real-time visibility for borrowers on their application progress.

Non-Functional Requirements

Security & Compliance: Strict encryption for PII (Personally Identifiable Information) and financial data (AES-256 at rest).

Data Integrity: Strong consistency is required for loan application states; we cannot have "lost" applications.

Availability: 99.9% availability; borrowers expect the portal to be accessible 24/7.

Scalability: Support up to 50,000 active users and 100,000 document uploads per month.

Estimation

Traffic: 10,000 Daily Active Users (DAU). Assuming a 1:10 write-to-read ratio for metadata.

Storage (Metadata): 50,000 applications/year * 10KB per record = 500MB/year (Negligible for modern DBs).

Storage (Documents): 50,000 applications 10 docs/app 2MB/doc = 1TB/year.

Bandwidth: 1TB/month upload volume

\approx

400KB/s average (easily handled by a single standard gateway).

Blueprint

Concise Summary: A classic three-tier architecture utilizing a modular monolith API for rapid development, backed by a relational database for transactional integrity and object storage for heavy documents.

Major Components:

Web/Mobile Client: React/React Native frontend for borrowers and agents.

API Gateway: Entry point for authentication, rate limiting, and request routing.

Application Server: A modular monolith handling Auth, Loan Logic, and Document Metadata.

PostgreSQL: Primary data store for user profiles, loan applications, and audit logs.

Redis: Low-latency cache for session management and frequently accessed lookup data.

S3 Object Storage: Secure repository for high-volume binary document data.

Message Queue (SQS): Asynchronous buffer for non-blocking tasks like sending emails or generating PDFs.

Simplicity Audit: This design avoids microservices and complex data streaming. By using a modular monolith and managed services (S3/RDS), the team can focus on business logic and security rather than infrastructure orchestration.

High Level Architecture

Sub-system Deep Dive

Service

Topology & Scaling: The App Server is deployed as a Dockerized modular monolith across multiple availability zones. It scales horizontally based on CPU/Memory utilization.

API Spec:

POST /v1/applications: Submit new loan data.

GET /v1/applications/{id}: Retrieve status.

POST /v1/documents/upload-url: Generate an S3 Pre-signed URL for secure client-side upload.

PATCH /v1/applications/{id}/status: Agent-only endpoint to move the workflow forward.

Communication: REST over HTTPS. Internal communication with Redis/DB uses connection pooling to manage overhead.

Storage

Data Model:

Users: user_id (PK), email, password_hash, role (borrower/agent).

Applications: app_id (PK), borrower_id (FK), status, loan_amount, created_at.

Documents: doc_id (PK), app_id (FK), s3_key, doc_type, verified_status.

Database Logic: PostgreSQL is chosen for ACID compliance. Indexes are placed on borrower_id and status for fast dashboard filtering. Row-level security (RLS) or application-layer checks ensure borrowers only see their own data.

Cache

Data Structures: String-based keys for session tokens (session:token_id -> user_payload).

TTLs: 24-hour expiration for sessions; 1-hour expiration for static configuration data (e.g., current mortgage rates).

Eviction: LRU (Least Recently Used) to ensure the most active users remain in memory.

Messaging

Topic Structure: A single "Task Queue" (e.g., AWS SQS).

Delivery Guarantees: At-least-once delivery. Consumers (Notification Workers) are idempotent to prevent duplicate emails.

Consumers: A small worker process listens to the queue to trigger SendGrid/Twilio APIs, decoupling the main request-response cycle from external network latency.

Wrap Up

Advanced Topics

Trade-offs: We prioritize Consistency over Availability (CP in CAP) regarding the loan application state. It is better for the system to be briefly unavailable than to permit a "lost" application or inconsistent loan amount.

Bottlenecks: The primary bottleneck will likely be the manual document review process. From a system perspective, S3 bandwidth is the secondary bottleneck, mitigated by using Pre-signed URLs to offload traffic from the App Server.

Failure Handling:

Multi-AZ RDS: Automatic failover for the database.

S3 Versioning: Protects against accidental deletion of sensitive borrower documents.

Dead Letter Queues (DLQ): Captures failed notification tasks for manual retry.

Alternatives & Optimization:

Alternative: Using NoSQL (DynamoDB) for applications. Reason for Rejection: The relational nature of loans, users, and documents benefits significantly from SQL joins and strict schemas.

Optimization: Implement OCR (Optical Character Recognition) via AWS Textract in the future to automate the validation of paystubs, reducing agent workload.