Varun Sangani
← All writing

Personal Notes App

Jun 27, 2026 · 0 min read · TAG, TAG

The problem

Design a personal notes app (like Apple Notes or Google Keep). A user can write notes on their phone, and see those same notes on their laptop. Keep it to a single user's own notes syncing across their own devices — no sharing or collaboration with other people.

Clarifying questions

Before designing anything I’d want answers to:

  • Works Offline? Affects sync status and consistency. Yes, required.
  • Same notes edited on two devices offline? Affects consistency. Must be handled.
  • Real-time editing across devices? Affects Latency. Few seconds refresh is okay, no live keystrokes sync.
  • Autosave? Affects write frequency and durability. Yes, no explicit save button.
  • Can you search through the notes? Introduces new latency and scalability requirement. Basic full-text, in scope.
  • What kind of attachments are allowed? Affects storage and bandwidth. Text plus small images, no videos.

Actors & requirements

Actors

  • Creator, Reader and Editor of the notes, operating across multiple devices.

Functional requirements

  • Create a note.
  • Read a note.
  • Update / Edit a note.
  • Delete a note.
  • List / Search a note.
  • Sync changes across user's devices.

Non-functional requirements

  • Durability: Never lose committed data, includes notes that are edited offline.
  • Eventual Consistency (AP): offline editing forces this requirement.
  • Latency: local read/writes are instant, sync propogation can be relaxed (seconds).
  • Throughput / Scalability: modest per user.

Back of the envelope

Metric Estimate Notes
Daily active users X M Assumption or source
Peak writes/sec ~X k How you derived it
Peak reads/sec ~X k Read:write ratio
Storage per year ~X TB Avg object size × write rate
Bandwidth (inbound) ~X Gbps Avg payload × writes/sec
The number that drives everything

STATE THE ONE SCALE CONCLUSION that shapes the design — e.g. “X k writes/sec means we can’t afford a single SQL writer.”

High-level design

NARRATIVE OVERVIEW — one paragraph describing the system end to end before going deep.

High-level architecture diagram
CAPTION — e.g. “Request flow from client through gateway to storage layer.”

Component: NAME

What it does and why it sits here.

Component: NAME

What it does and why it sits here.

Low-level design

WHICH COMPONENT are you going deep on, and why this one over the others.

Low-level design diagram
CAPTION

Data model

TABLE / SCHEMA NAME
  field_name   TYPE    -- note
  field_name   TYPE    -- note

Critical path: NAME

Walk through the most important sequence step by step.

  1. Step one.
  2. Step two.
  3. Step three.

Risks & trade-offs

None of these are blockers. They’re things I’d want a decision on before we shipped.

  • RISK. Explanation and mitigation.
  • RISK. Explanation and mitigation.
  • RISK. Explanation and mitigation.
OPTIONAL CLOSING THOUGHT — a one-liner that captures the core judgment call.

What I’d actually recommend

SUMMARY RECOMMENDATION in 2-3 sentences. What to build, what to defer, and what to write down.

Filed under: TAG, TAG. Got a sharper take or a war story? Tell me.