System Design: An E-Signature Service Like DocuSign With Tamper-Evident Audit Trails

Design a service like DocuSign that lets people send documents to others for electronic signature and sign them online. ```hint Proof outlives the signature Moving a document between people is the easy part. Think about what the service would need to show, months later, about who signed, when, and which exact version of the document they saw. ``` ### Clarifying Questions - Is the scope one sender collecting signatures from one or more recipients, or also templates, bulk sending and signing embedded inside other apps? - Which legal frameworks must the signatures satisfy, and do some documents need stronger proof of the signer's identity than access to an email inbox? - Must recipients be able to sign without creating an account? - What scale should we plan for, in documents per day and typical document size? ### What a Strong Answer Covers - Requirements for senders and signers, with a stated scale estimate and the legal and security needs that shape the design. - The core data model (envelopes, documents, recipients, signature fields, audit events) and the APIs for creating, sending, signing and retrieving. - The signing workflow: routing order, notifications, reminders, expiry, voiding, and the state machine that keeps it consistent. - Tamper evidence and an audit trail for completed documents, plus security of documents and signing links. - Scaling document storage and rendering, failure handling, and the metrics a PM would watch. ### Follow-up Questions - A signer claims they never signed. What evidence can the service produce, and where in the design does each piece come from? - The sender voids the envelope at the same moment the last signer clicks finish. What happens? - How would you add stronger identity checks for high-value documents without hurting completion rates?