Real-Time Family Coordination: Notes on Sync Architecture

Here is a scenario that happens a thousand times a day across Honeydew households. Dad is at the grocery store. Mom, at home, remembers they need milk. She tells Honeydew to add it to the list. Dad is in the dairy aisle. If the sync takes five seconds, he has already walked past the milk. If it takes thirty seconds, he is in the checkout line. If it takes "next time you open the app," there is no milk at breakfast.

Real-time sync is not a feature for a family coordination app. It is the product. Everything else — the AI, the lists, the calendar — is worthless if the family is not working from the same source of truth at the same moment.

This article is a founder-level perspective on how we think about real-time sync in Honeydew: the design principles, the hard problems, and what we've learned. I'm deliberately staying high level on implementation specifics — the plumbing changes as we optimize, and it's not the interesting part of the story.

---

Why Low Latency Matters

There's a well-studied threshold in user experience. Actions that complete under about 100ms feel instantaneous. Under a second, users notice delay but stay in flow. Beyond that, attention breaks.

For collaborative apps, the bar is higher. When two people are interacting with the same shared thing, the delay between one person's action and the other person seeing it determines whether the experience feels like collaboration or like taking turns. Google Docs set the expectation: real-time means you see the other person's changes as they happen, not on the next refresh.

We aim for the "feels instant" band for sync between connected devices in the common case, and for graceful degradation in the bad cases (weak cellular, subway tunnels, WiFi dead zones). We don't publish exact latency numbers — they change as we optimize, and the architectural story is what matters.

---

Design Principles

Rather than walk through the stack layer by layer, let me cover the principles, because those are what we'd do the same way if we started over.

Local-First

Every Honeydew client maintains a complete local copy of the family's data that's relevant to that user. When you add an item to a list, the change is applied locally first, rendered immediately, and then propagated. That has a few big consequences:

• The app never feels slow, even on bad connections.
• The app works fully offline.
• The user sees their own changes with zero latency.

Local-first is structural. It's easy to bolt slowness-hiding tricks onto an online-only architecture, but you can't bolt real offline support onto one. Build the foundation correctly up front and everything downstream gets easier.

Persistent, Low-Overhead Connections

For the sync channel, we need bidirectional, low-overhead, low-latency communication between clients and the server. Polling is wasteful and adds half the poll interval in average latency. One-way push channels only solve half the problem. A persistent bidirectional connection per client is the right shape for a sync protocol sending many small messages.

The tradeoff is that persistent connections require more infrastructure care — connection management, reconnection and backoff, heartbeats, horizontal scaling across instances. But for the latency bar we care about, the alternatives just don't work.

Event-Based State

Every mutation in Honeydew — adding a list item, checking off a task, moving a calendar event — is captured as an immutable event. That gives us several properties that matter for a family app:

• A complete audit trail. Every change has a who, a what, and a when. "Who deleted the soccer game from the calendar?" is answerable. That's not just a debugging convenience; it's a trust feature in a shared household system.
• Temporal queries. We can reconstruct the state of any entity at any past point.
• Conflict resolution context. When two users edit the same entity concurrently, we have the full history of both edit sequences rather than just their final values.
• Replay and recovery. If a client's local state gets corrupted (rare, but it happens), it can be rebuilt from the event log. No data is truly lost.

We deliberately don't publish our event schema. The architectural point worth making is that treating changes as first-class events rather than as direct state mutations is what makes everything downstream tractable.

Conflict-Free Merges for Concurrent Edits

Families don't coordinate their edits. Mom and Dad don't say "I'll edit the grocery list now, please wait." They both edit simultaneously, often from different locations, sometimes while one device is offline.

We use a conflict-free merge strategy designed for exactly this shape of data — concurrent edits that need to converge to the same final state across all devices, regardless of the order events are received. Two people adding items to a list simultaneously both get their items preserved. Edits to different fields of the same event (Mom changes the title, Dad changes the location) both land. When two people edit the same field, the "loser" isn't silently dropped — it's preserved in the event history so it can be recovered, and in some cases we surface it to the user.

The deeper architectural point: pick a merge strategy that preserves intent under concurrency from day one. The wrong strategy loses user data quietly, and "we'll fix the merge logic later" is the kind of promise that ages badly. Family lists are a small but real distributed-systems problem.

Offline-First, Not Offline-Tolerant

Offline isn't a degraded mode. It's a first-class use case. Families use phones in places with no signal constantly — subway commutes, school drop-off zones with terrible coverage, grocery-store warehouses, rural roads, the one corner of the house where WiFi doesn't reach.

When a device regains connectivity, the sync process reconciles what each side missed, applies the merge strategy for any concurrent edits during the offline period, and converges. The UI doesn't block during sync. The user keeps using the app with local state while reconciliation happens in the background. If a merge changes something the user is looking at, the change animates in smoothly rather than replacing the screen.

For long offline periods — a camping trip, a week in a cabin — we show a short summary when you reconnect: what happened while you were away, what was merged, what conflicts (if any) got resolved. Transparency builds trust. The family knows the system handled it, they can see what happened, and they can correct anything that was merged the wrong way.

---

External Calendar Sync: The Two-Way Problem

Families don't use one calendar. They use a mix of personal calendars, school calendar portals, work calendars, and sports team apps. Honeydew needs to be a unified view, which means bidirectional sync with external calendars.

Some external calendars support push-style updates; others only support polling. We use push where available and polling as a fallback, balanced against the external service's rate limits. Events created in Honeydew appear in linked external calendars; events created externally appear in Honeydew.

Deduplication

Bidirectional calendar sync deduplication is harder than it sounds. Consider: Mom creates "Soccer Practice, Saturday 10am" in Honeydew. It syncs out to the shared external calendar. Dad, who has the same external calendar linked, opens Honeydew. The inbound sync sees "Soccer Practice, Saturday 10am." Is this a new event or the one Mom just created?

We handle this with a combination of stable identifiers stored in the external calendar's metadata, fuzzy matching as a fallback for events that originated outside Honeydew, and user confirmation for genuinely ambiguous cases. It's not perfect — but false positives (asking about a possible duplicate) are far less damaging than false negatives (silently creating duplicate events).

---

Multi-Household Families

Here's a requirement that most collaboration apps don't handle gracefully: divorced and blended families. Honeydew has households where two parents share custody, each has their own partner and household, some data is shared across households (kids' activities, school schedules, medical info) while other data is private (household grocery list, private events), and step-parents may have read access to some shared data but not edit access.

We model this with three concepts: household (a unit that shares a kitchen, shared lists, shared routines), family group (a cross-household group defined by shared children), and entity-level permissions (each list, event, or task has a visibility scope: household-only, family-group, or explicitly shared).

The sync layer enforces these permissions on every event. The server authenticates the sender, verifies write permission on the target entity, determines the fan-out set (which connected clients should receive this event), and filters the payload based on each recipient's permission level. This has to be fast — permission checks can't eat the latency budget — so we keep the data structures that back permission checks simple and constant-time.

Multi-household is one of the places where the structural choices matter most. Half-built permission models in consumer apps routinely leak private data across households, and "oh, your ex-spouse can see your grocery list" is the kind of bug that destroys trust instantly.

---

Edge Cases That Bit Us

Timezones

Dad is in New York. Mom is in Los Angeles for a business trip. She says "add dinner to the calendar at 7pm." Whose 7pm?

This looks simple until you consider: Mom's phone is in Pacific time; the family calendar's "home" timezone is Eastern; Dad expects Eastern times; if the dinner is at a restaurant in LA, she means Pacific; if it's a reminder for something back home, maybe she means Eastern.

All times are stored in UTC internally, and display conversion uses the viewer's timezone by default. When there's genuine ambiguity — user speaking outside their home timezone, no explicit timezone stated — the assistant asks rather than guessing. This took multiple rewrites to get right. The first version assumed home timezone always. The second assumed device timezone always. The current version uses context and asks when uncertain.

Simultaneous Edits to the Same Field

Two parents editing the same grocery list item in the same moment is rare but real. Our merge strategy picks a deterministic winner for the text of a single field, but the losing edit isn't discarded — it's preserved in history, and when the collision is meaningful we surface it ("Sarah also edited 'Milk' — she wrote something different; tap to update"). We chose a field-level approach rather than character-level merging because character-level merging is justified for collaborative documents, not for grocery-list items.

Long Offline Periods Spanning App Updates

The gnarliest edge case: a device has been offline for days with a queue of local changes, and during that time the data model has evolved because we shipped an app update that other family members already installed.

We handle this with schema versioning on events and the ability to transform events between schema versions when they're received. Backward compatibility is maintained for a bounded window of releases; beyond that, the device needs to update before syncing and we show a clear message explaining why.

---

Engineering Tradeoffs, in Retrospect

A few opinions from the other side of building this.

Eventual consistency was the right call. We considered strong consistency — every device sees the same state at the same time, with locking. For a family app that would mean Dad's grocery list shows a loading spinner because Mom is editing. That's wrong for the use case. Families need to be able to independently interact with shared data without coordination. Eventual consistency with a good merge strategy means both can edit simultaneously and the system converges — usually fast enough that neither of them notices.

Offline-first from day one was worth the cost. Building offline-first from the beginning was more expensive than bolting it on later would have been. But it informed every subsequent architectural decision — the local-first data layer, the event-based model, the merge strategy. Bolting offline onto an online-only architecture would have meant rewriting the data layer. If you're building a mobile-first collaborative app: build offline-first from day one.

Design for concurrent edits as architecture, not as a feature. The wrong merge strategy loses data quietly, and the bugs don't surface in testing — they surface when real families are using real devices in real conditions. Picking a merge approach that preserves intent under concurrency is a day-one decision, not a later one.

---

Frequently Asked Questions

How does Honeydew sync data across family devices?

Honeydew is built local-first. Every client keeps a complete local copy of the relevant data, changes apply locally with zero latency, and updates propagate to other family members' devices in the background. For the common case on a decent connection, other family members see the change quickly enough that it feels like real-time collaboration.

Does Honeydew work offline?

Yes. Honeydew is designed offline-first. The app maintains a complete local copy of your family's data and works fully without internet. Changes made offline sync automatically when connectivity is restored, with intelligent conflict resolution for any concurrent edits.

How does Honeydew handle conflicts when two family members edit the same thing?

Honeydew uses a conflict-free merge strategy that preserves intent under concurrency. Simultaneous additions to the same list both succeed. Edits to different fields of the same item both land. When two people edit the same field at the same time, one change wins deterministically and the other is preserved in history — and where the collision matters, we surface it so the family can resolve it.

How does Honeydew handle calendar sync with external calendars?

Honeydew syncs bidirectionally with major calendar providers, using push-style notifications where available and polling where not. Events created in Honeydew appear in linked calendars and vice versa, with deduplication to prevent duplicate entries.

How does Honeydew handle divorced or blended family data sharing?

Honeydew supports multi-household family groups with granular permissions. Each household has private data (grocery lists, routines) and family groups share relevant data (children's activities, custody schedules). Entity-level permissions control visibility, and the sync layer enforces those permissions on every change.

---

Related Reading

• How Honeydew's AI Agent Works
• Building a Multimodal AI Family Assistant
• How Honeydew's Knowledge Graph Learns Family Patterns

---

Get Started with Honeydew

Honeydew AI Family Organizer turns voice messages, photos, and plain-English text into organized family plans. Free to start, $7.99/mo for Premium (or $79.99/year).

Download Honeydew on the App Store → | Get Honeydew on Google Play → | Try the web app