System Design: Guardian Acknowledgement Messaging Platform

Context

Design a system that enables school staff to send messages to students' guardians, where guardians must acknowledge receipt. Assume multi-channel delivery (email, SMS, and in-app push), multiple guardians per student, and potentially large rosters. Acknowledgements may be required from any one guardian or from all guardians, depending on the message.

Requirements

1. Sender and Recipient Management
   • Staff roles and permissions (e.g., teacher can contact only their classes; admins can broadcast).
   • Rosters from the student information system (students, guardians, relationships, preferred language).
   • Groups and targeting (class, grade, school, custom lists, dynamic filters).
   • Guardian identity and contact management (multiple channels, verification, deduplication).
2. Reliable Message Delivery
   • Queueing, retries with backoff, idempotency, and provider failover (e.g., primary and secondary SMS/email vendors).
   • Delivery status tracking (queued, sent, delivered, bounced, failed) via provider webhooks.
   • Rate limiting, throttling, and quiet hours.
3. Acknowledgement Capture and Reminders
   • One-click, signed link per guardian per message; SMS keyword reply and in-app button.
   • Configurable acknowledgement policy: ANY or ALL guardians per student; due-by time.
   • Reminder scheduling until acknowledgement or deadline.
4. Escalation
   • Rules to escalate if acknowledgement(s) not received by deadlines (e.g., call, voicemail/IVR, notify admin/counselor).
   • Manual override and bulk re-send.
5. Audit Trails
   • Immutable events for who sent what to whom and when, delivery and acknowledgement events, reminders, and escalations.
   • Tamper-evident logs and access logs.
6. Privacy and Consent
   • Channel-specific consent and opt-out; purpose limitation; data minimization.
   • Encryption in transit and at rest, RBAC, data retention, and data subject requests.
7. Reporting
   • Real-time and historical dashboards: delivery rate, acknowledgement rate, time-to-acknowledge, by class/grade/sender/channel.
   • CSV export and API access.
8. Non-Functional Constraints
   • High availability for sending and acknowledging.
   • Scalability to tens of thousands of students and guardians.
   • Localization (language, timezone) and accessibility.

Deliverable

Provide a system design that specifies how you'll meet these requirements, including core components/services, data model (key entities), message and acknowledgement flows, reliability mechanisms, security/privacy controls, and reporting. Include assumptions where needed.