System Design: Property Management System

Requirements

Functional Requirements:

• Tenant application flow with background check integration and digital lease signing
• Rent collection with recurring ACH payments, late fee automation, and payment history
• Maintenance request submission with photo upload, status tracking, and vendor assignment
• Lease management: renewals, rent adjustments, move-out inspections, and security deposit handling
• Owner/manager dashboards showing occupancy, rent roll, maintenance costs, and NOI
• Multi-property support for landlords managing 1 to 10,000+ units

Non-Functional Requirements:

• Payment processing must be NACHA-compliant for ACH transactions
• Lease documents must be legally valid electronic signatures per ESIGN Act
• 99.9% uptime for tenant rent payment portal — payment failures cause financial stress
• Audit trail for all financial transactions and lease amendments
• GDPR/CCPA-compliant handling of tenant PII and financial data

Scale Estimation

For a large platform: 5M rental units managed, average 1.2 tenants per unit = 6M tenants. Monthly rent payment processing: 5M units × $1,500 average rent = $7.5B/month in ACH transactions. Maintenance requests: 5M units × 1 request/unit/month = 5M requests/month = ~2.3/second. Lease document signings: 5M units × 30% turnover/year = 1.5M new leases/year = ~4/second. Background check API calls: 1.5M new applications/year = ~4/second.

High-Level Architecture

The system is structured around a Lease Lifecycle Service, a Payment Platform, and a Maintenance Service. The Lease Lifecycle Service manages the tenant journey from application through lease signing, occupancy, renewal, and move-out. The Payment Platform handles recurring rent collection, late fee assessment, and security deposit management through ACH processing via a banking API (Plaid for bank verification, Dwolla or Stripe Treasury for ACH execution). The Maintenance Service is a ticketing system adapted for property maintenance workflows.

Multi-property support requires a multi-tenant data model at the property management company level — not the tenant level. A management company manages many properties, each with many units. The data model uses management_company_id as the top-level scope, with row-level security policies ensuring managers only access their properties. Landlords managing a single property use the same system as large institutional managers, just with a single-property scope.

Background checks integrate with third-party providers (TransUnion SmartMove, Checkr). The integration is async: the application triggers a check, the provider sends a webhook on completion, and the result updates the application record. Landlord notification is sent via email and in-app when the report is ready. Sensitive report data is stored encrypted and auto-deleted after the retention period required by the FCRA.

Core Components

Lease Lifecycle Service

Manages application, approval, lease creation, and renewal workflows as state machines. Application states: submitted → background_check_pending → approved/rejected → lease_sent → signed → active. Lease documents are generated from templates with merged tenant and unit data, stored as PDFs in S3, and sent for e-signature via DocuSign or HelloSign API. Signed documents are retrieved via webhook and stored in an immutable document vault. Lease amendments are addenda to the original lease — the original document is never modified.

Payment & ACH Platform

Handles recurring rent collection on a configurable due-date schedule. Bank accounts are verified via Plaid instant verification or micro-deposit. ACH origination files are generated daily and submitted to the bank by 3 PM for next-business-day settlement. Payment status webhooks from the ACH provider update transaction records. Late fee rules are configured per property (e.g., 5% after 5 days grace period) and enforced by a nightly scheduled job. Security deposits are tracked in a separate escrow ledger, legally required to be segregated in many jurisdictions.

Maintenance Request Service

A ticketing system with photo attachment support. Tenants submit requests via mobile app or web portal. Requests are categorized by type (plumbing, electrical, appliance, HVAC) and priority (emergency, urgent, routine). Emergency requests trigger immediate SMS notification to the manager. Vendor assignment is either manual (manager selects from preferred vendor list) or automatic (rule-based routing by category + availability). Vendors receive requests via SMS and a vendor app with photo access and status update capability. Work order costs are tracked against units for owner reporting.

Database Design

Core schema in PostgreSQL: management_companies, properties (property_id, company_id, address, type, units_count), units (unit_id, property_id, unit_number, bedrooms, bathrooms, sqft, monthly_rent), leases (lease_id, unit_id, tenant_ids[], start_date, end_date, rent_amount, status), tenants (tenant_id, company_id, name, email, phone, dob_hash). PII fields (SSN, bank account) are tokenized via a vault service; only tokens are stored in the main database.

Payments: transactions (transaction_id, lease_id, type ENUM, amount, due_date, paid_at, status ENUM, ach_trace_number). Late fees: late_fee_events (event_id, lease_id, assessed_on, amount, paid_at). Maintenance: work_orders (wo_id, unit_id, tenant_id, category, priority, description, status ENUM, vendor_id, cost, created_at, resolved_at), wo_attachments (wo_id, s3_key, uploaded_by). An audit_log table captures every financial transaction state change and lease amendment with actor, timestamp, and change diff.

API Design

POST /api/v1/applications — tenant submits rental application; triggers background check.

POST /api/v1/leases/{leaseId}/sign — sends lease for e-signature via integration; returns signing URL.

POST /api/v1/payments/setup-autopay — tenant authorizes recurring ACH; returns bank verification flow.

POST /api/v1/work-orders — tenant submits maintenance request with optional photo attachments.

Scaling & Bottlenecks

The first-of-month rent payment batch is the main load spike. Sending 5M ACH transactions in a single batch window requires careful pipelining with the banking API. The system staggers due dates across a 5-day window (different properties have different grace periods) and processes ACH origination files in time-sorted batches. Webhook processing for payment status updates peaks on Day 2-3 post-submission as banks settle — the webhook handler must idempotently process duplicate status updates from the ACH provider.

Document generation and e-signature workflows are synchronous from the user's perspective (they expect an immediate signing link). PDF generation for complex leases can take 2-5 seconds. A pre-generation approach renders the lease PDF when the application is approved (before the manager clicks "Send for Signature"), storing it in S3, so the signing link is ready instantly when requested.

Key Trade-offs

• ACH vs. card for rent payments: ACH has low fees (0.5%) suitable for large recurring transactions but settles in 1-3 days and has high chargeback risk; card payments are instant but 2.5-3% fees on $1,500/month rent = $37.50/month in fees, often prohibitive.
• Template-based vs. attorney-drafted leases: Template leases are scalable and consistent but may not be jurisdiction-compliant without significant legal review investment; integrating with legal review services adds cost per lease.
• Synchronous vs. async background checks: Synchronous checks block the application flow until the report returns (usually 60-90 seconds) but feel responsive; async checks with a progress indicator are better UX for longer checks but require a webhook integration and notification flow.
• Centralized vs. per-property escrow ledger: A centralized security deposit ledger is simpler to manage but complicates jurisdiction-specific escrow rules; per-property escrow tracking maps directly to legal requirements but multiplies ledger complexity.