How we handle5,000+ contacts.

When people say they have 5,000 contacts, the number describes only the top-level cards. Each card can own phone numbers, email addresses, postal addresses, organizations, instant-messaging handles, websites, social profiles, dates, notes, photos, custom properties, provider accounts, group memberships, and links to other people. A typical card may be small, while a damaged server record may repeat the same property thousands of times. The memory and correctness cost therefore follows the shape of the object graph, not only the visible row count. An implementation that loads every relationship for every card at once can behave acceptably in a small demo and then collapse when it encounters one pathological contact.

There is another hidden dimension: identity can be transitive. Imagine that card A and card B share an exact phone number, while card B and card C share an exact email address. A direct comparison says A matches B and B matches C, so all three belong to one connected duplicate group even if A and C have no identical field. A useful detector must preserve that connection. At the same time, it must not assume that two people with the same common name are one person, and it must not combine unrelated records simply because they came from different accounts that happen to contain similar data.

This is why Cloud Contacts separates detection from mutation. Detection asks, “Which records are connected by defensible identity evidence inside a compatible provider domain?” Review asks, “Does the person using the app agree with this proposed group?” Merge asks, “How can the approved group become one richer card without dropping valuable fields?” Synchronization asks, “Which provider operations must follow so the cleanup is not undone on the next pull?” Treating those as separate questions creates clear safety checkpoints. It also lets the app cancel or report a failure without pretending an unfinished operation was a complete success.

The design target is bounded work, not a magical address-book size. Five thousand contacts is a useful public example because it is large enough to expose careless algorithms. The same architecture also matters for smaller lists with unusually large photos or property sets, and for much larger lists where the compact indexes themselves become the dominant cost. We deliberately avoid promising one universal completion time: device model, database history, image sizes, property counts, provider state, and the number and shape of duplicate groups all matter. What can be promised is the strategy—small in-memory object working sets, deterministic progress, cancellation checkpoints, and no intentional all-pairs graph.

The most obvious duplicate detector uses two loops. Take the first contact and compare it with every later contact, then take the second and compare it with every later contact, and continue until the list ends. With 5,000 contacts, that means nearly 12.5 million unordered pairs before counting the work required to normalize and compare multiple fields. At 10,000 contacts, the pair count approaches 50 million. If a program also stores every matching edge for later grouping, memory grows with the number of candidate relationships. A popular shared business phone or placeholder email can create an especially dense graph.

Cloud Contacts changes the question from “Does this card match every other card?” to “Have we already seen this identity key in the same compatible account domain?” As each contact is reduced to normalized keys, a compact dictionary maps each scoped key to one representative contact index. When the same key appears again, the grouping structure connects the current contact to that representative. The dictionary does not need a list of every contact that ever used the key, and the app does not need an adjacency matrix or a stored edge for every pair.

The grouping structure is union-find, also called disjoint-set union. It maintains a parent relationship for contact indexes. Joining two indexes connects their sets; finding the root tells us which final group an index belongs to. Path compression keeps repeated lookups efficient. The important product effect is transitivity: if one card connects through a phone and another connection continues through an email, the final group still represents the whole chain. The important memory effect is that the detector stores compact indexes and parent integers instead of a graph full of managed contact objects.

This does not mean every aspect is constant memory. The detector still keeps the ordered active object IDs, normalized scalar keys, one representative per scoped key, and the union-find arrays for the current scan. Those structures grow roughly with the number of contacts and distinct keys, which is an honest and manageable tradeoff. What it avoids is quadratic comparison work and quadratic relationship storage. For a public promise, “we use indexed grouping instead of a 5,000 by 5,000 object comparison” is more meaningful than an unsupported claim that memory can never grow.

An object database makes it convenient to navigate from a contact to its phone numbers, emails, accounts, and other relationships. That convenience can be dangerous in a large operation. Holding an array of live contacts and traversing many relationships can materialize complete object graphs. Photos and repeated properties magnify the effect. Even if the algorithm later needs only a few strings, the process may retain far more data than the comparison requires. The safest large-operation currency is therefore not a live object. It is a persistent object ID: a compact storage reference that an isolated data context resolves only when the object is needed.

The duplicate scanner first fetches the IDs of available contacts. “Available” matters: contacts already marked as deleted, deleting, or remotely deleted must not return as candidates or inflate available-contact counts. The IDs are placed in deterministic URI order so the same database state produces stable traversal and representative selection. This stable order improves reproducibility in tests and makes a cancelled or retried scan easier to reason about. It also prevents results from depending on an accidental fetch order that may differ across devices or database histories.

Once the ID snapshot exists, the scanner can open an isolated read context and resolve only a small slice. Later, the merge engine can pass groups of IDs to a serial worker and create fresh transaction contexts for the actual writes. A callback, progress reporter, or result object does not need to capture thousands of interface-layer objects. This respects concurrent database access as well as memory lifetime: live objects remain inside their owning context and execution queue, while persistent IDs are safe to pass across those boundaries.

There is a subtle consistency benefit too. The scanning context uses a stable read snapshot when possible, giving detection a coherent view of persistent storage rather than silently mixing old and new versions during a long read. The merge phase still revalidates each candidate group before changing anything because the user or a sync process may have edited records after detection. Snapshotting makes detection consistent; revalidation makes mutation cautious. Neither one substitutes for the other.

Cloud Contacts advances the duplicate scan through outer windows of 200 contact IDs. That outer window is useful for progress reporting and cancellation. It gives the operation a predictable point to update the interface and check whether the person has asked it to stop. But the app does not materialize all 200 contact graphs simultaneously. Inside each window, it loads contact objects in groups of at most 25 and reads only the relationships required for identity detection: phone numbers, email addresses, and provider accounts.

Each 25-contact fetch runs inside a scoped memory-release boundary. The scanner turns active fields into normalized scalar keys, adds those keys to the streaming index, and then releases the materialized state of unchanged contacts. The full property graph therefore does not remain resident merely because it was inspected. When the scope ends, temporary runtime objects can be reclaimed promptly. This is especially important on memory-constrained mobile devices, where a long-lived background task shares finite resources with the interface and the operating system.

Why not pick one giant batch to reduce fetch overhead? Because peak memory is determined by the worst contact graph in the batch, not just the average. Twenty-five contacts can already include large photos or a broken card with thousands of repeated properties. Smaller batches lower the damage radius. Why not fetch one contact at a time? That would minimize the instantaneous graph but increase store round trips and bookkeeping. The chosen constants are engineering controls, not performance trophies: they define a restrained working set while still allowing efficient database access.

The same principle appears elsewhere in provider synchronization. Large Google, Microsoft, CardDAV, system address book, and JMAP flows reduce records to scalar snapshots or persistent object IDs, use bounded fetch or request groups, and avoid handing live database objects to network callbacks. The exact network limits vary by provider—for example, a remote API can impose its own batch maximum—but the design rule remains: fetch or serialize the data needed for the current checkpoint, save it, release it, and then continue.

A duplicate detector cannot treat raw text as identity. The phone numbers “+1 415 555 0100,” “(415) 555-0100,” and a local presentation of the same number may describe one endpoint. Email case and surrounding whitespace should not create separate people. On the other hand, aggressively stripping information can create false positives: phone extensions matter, malformed addresses should not become authoritative keys, and a blank value must never connect a large group of unrelated records. Normalization is therefore a controlled interpretation step, not a generic remove-every-symbol function.

Cloud Contacts creates normalized name, phone, and email keys for active properties. Deleted phone and email tombstones are excluded so an old value awaiting synchronization does not resurrect a duplicate group. Empty keys are discarded. The exact automatic cleanup path uses credible normalized phone and email evidence. Names are intentionally absent from that exact mode, because two people can be called Alex Chen, Maria Garcia, or John Smith without being duplicates. Name evidence is valuable for discovery, but it belongs in a suggestion the user can review.

This distinction is one of the most important product safety rules. “Exact” does not mean metaphysically certain that two cards represent the same human; shared household numbers and role-based email addresses still exist. It means the app has stronger equality evidence than a visual name resemblance. “Review” broadens discovery to normalized names and presents the result as a decision, not a fact. The interface can show provider ownership and the useful properties on each candidate so the person making the decision can recognize a spouse, coworker, namesake, or obsolete card.

Normalization also improves consistency across other workflows. System-address-book write-back and provider import matching use compatible identity concepts so the same formatting difference does not produce one result during duplicate review and a contradictory result during sync. A product earns trust when its identity rules are explainable and reused. It loses trust when each screen invents a different definition of “same contact.”

A multi-provider address book creates a difficult choice. Users want to recognize that the same person exists in iCloud, Google, Outlook, or CardDAV, yet each remote service owns its own card and remote identifier. Blindly merging across every source can leave one local object responsible for contradictory remote lifecycles. Deleting a source card might remove the wrong remote record; updating a survivor might push fields into an account that never owned them; a later provider pull might recreate what appeared to be cleaned.

Cloud Contacts scopes duplicate keys with an account domain derived from the contact's complete provider membership set. Candidates are joined only when that domain is compatible. A contact with no provider account is not silently folded into a provider-backed card, and two cards with different non-empty membership sets do not become one destructive automatic group merely because one normalized key matches. The merge function checks the domain again before combining, creating a second barrier between a broad discovery bug and an irreversible mutation.

To a user, this may look more conservative than an app that reports a very large duplicate count. That is intentional. A duplicate count is not a score, and a merge is not more intelligent because it is more aggressive. Cloud Contacts would rather leave an ambiguous cross-provider situation available for an explicit copy, move, or sync workflow than invent ownership. Provider badges on contact rows and provider names in detail views help make the boundary visible instead of hiding it inside the database.

There is still a unified human experience. The app can display a contact's multiple owners, carry group memberships, and preserve relationships during a compatible merge. It can also help a user copy or export data between services. The constraint is about destructive identity consolidation: remote ownership must remain traceable. The application treats “this is probably the same person” and “these remote records have the same lifecycle” as related but different statements.

Suppose the scan sees three contacts. The first contributes a phone key and becomes that key's representative. The second has the same phone, so union-find joins their indexes. The second also contributes an email that the first does not have, and becomes the representative for that email. When the third contact arrives with that email, the third index joins the existing set. No code needs to go back and compare the third card with the first. The parent structure already knows that the chain belongs to one component.

After the stream is indexed, the detector walks the contact indexes, asks union-find for each root, and gathers IDs by root. Single-item roots are ordinary contacts and disappear from the duplicate result. Multi-item roots become groups. Stable ordering is retained so the review interface does not reshuffle arbitrarily. The detector can calculate progress from the IDs already traversed rather than from an unknowable number of pair comparisons.

The representative rule matters for dense keys. If one office main line appears on 500 cards, the index retains one representative for that scoped key and joins each later card to the same set. It does not append 500 objects to the key bucket and later compare all combinations. This controls the structure's growth, although the product still needs conservative identity rules because a shared office number may not prove that all 500 cards are one person. Exact textual equality makes an efficient candidate connection; user intent and provider rules still decide whether automatic consolidation is appropriate.

From a security perspective, compact scalar indexes also reduce incidental exposure inside the process. A matching table needs normalized keys and object indexes, not photos, full notes, street addresses, or relationship histories. Data minimization is useful even when computation is on-device: the smallest structure that can answer a question is easier to reason about, easier to release, and less likely to be captured in a diagnostic description. Cloud Contacts carries rich data into the merge only after a group has passed detection and validation.

Duplicate cleanup has two different user intentions. Sometimes a person wants a review queue: show likely overlaps, provide enough context, and let the user decide which cards belong together. Sometimes the person has an obviously damaged import with repeated exact phones or emails and wants a long-running automatic cleanup. These intentions should not share the same evidence threshold. Cloud Contacts therefore keeps review matching and exact matching as explicit modes rather than a single hidden confidence number.

Review mode includes normalized name keys along with phone and email keys. Its output is a proposal. The app can select a primary card, display the most useful properties rather than thousands of redundant rows, and offer a total Fix entrance for the whole contact. Where a contact contains enormous redundant-property counts, the UI must remain responsive and keep the action visible; detection work should be bounded and cancellable rather than blocking the button until every property has been rendered. Long-press copy actions let users preserve an individual value before they make a larger decision.

Exact automatic mode excludes names and relies on active normalized phone or email equality. Even then, the engine revalidates the group immediately before mutation. A sync may have changed a phone, an account may have been removed, or another cleanup may have altered the group after detection. If the current identity no longer supports the requested mode, the group stops safely instead of applying an old conclusion. This is optimistic workflow with pessimistic validation: discover efficiently, verify at the write boundary.

The distinction also improves messaging. A review result can say “possible duplicates” or “similar contacts,” while an automatic result can say how many exact groups were combined. A cancelled operation can report partial progress without calling the remaining cards fixed. Words such as “perfect,” “guaranteed,” or “all duplicates removed” would be misleading because identity is contextual. Honest status language gives the user a realistic model of what happened and what still needs attention.

Merging is not deleting all but one card and hoping the remaining card was the best. The engine first chooses a master. If the user or a previous batch already selected a preferred master, that identity remains stable. Otherwise, the batch workflow looks for a valid contact with a photo and falls back to the first valid contact in deterministic order. Photos are not proof of identity, but preferring an existing richer visual record is a practical way to preserve the card users are most likely to recognize.

Stability becomes essential when a large duplicate group is divided into 25-source batches. The first transaction may combine only part of the group. The next transaction must continue into the same survivor; choosing a different master for each batch would create a chain of intermediate cards and make partial completion hard to understand. Cloud Contacts carries the master object ID forward, resolves it in each fresh transaction context, and orders source processing so later batches remain connected to keys that are already represented by the master or by earlier validated sources.

Before a batch writes, the engine filters out deleted, deleting, and remotely deleted records and verifies that the group still shares the required identity evidence and account domain. A source that vanished or changed cannot be treated as if the old scan were current. If no valid master remains, or the identity validation fails, that group is reported as unfinished. Other independent groups can continue, so one damaged cluster does not force an all-or-nothing failure across thousands of contacts.

For the person using the app, the survivor should feel like the most complete version of the person, not like an arbitrary database row. That is why master choice is followed by field preservation rather than field replacement. Existing useful master values remain, missing values can be filled from sources, property collections are canonicalized, notes can be retained with clear separation, and the survivor is marked as changed for synchronization only after the local transaction succeeds.

Once duplicate groups are approved, Cloud Contacts submits their object IDs to a serial merge queue. Serial ordering prevents two merge writers from racing over the same records. A group is divided into source batches of at most 25 contacts around its stable master. Each batch creates a fresh transaction context, disables undo tracking, uses an error-reporting conflict policy, resolves only the IDs it needs, and performs its work inside a scoped memory-release boundary. When the batch ends, the entire context and its object graph can be released rather than accumulating throughout the job.

The save is the durability checkpoint. Progress is not advanced merely because values were copied in memory; the engine counts work after the batch transaction has succeeded. Saved object IDs are then published to the interface data context so the visible state can reflect the persistent result without performing the heavy work itself. Cleanup side effects—such as removing stale recap references, updating recent-contact state, notifying contact views, and recording deletion events—are coordinated after durable changes rather than before them.

If a batch fails validation or saving, the engine records the group index and the remaining IDs. Previously saved batches remain valid. The result distinguishes complete success, partial completion, failure, and cancellation. This is more useful than a single Boolean because a long operation can legitimately have committed work before the person taps Cancel or before one unusual record triggers a store error. The UI can say what was completed, what remains, and whether a retry is appropriate.

Small transactions do introduce overhead: contexts are created repeatedly and each save reaches the persistent store. That is a deliberate exchange. A single enormous transaction could reduce save overhead, but it would retain a huge change graph, create a large rollback scope, delay visible progress, and turn one bad object into a failure for the entire cleanup. For personal data, bounded recovery and clear checkpoints are more valuable than maximizing a synthetic records-per-second benchmark.

Consider two cards for the same person. The first has a carefully cropped photo, personal mobile number, and birthday. The second has a current job title, work email, office address, and a note from the last meeting. Selecting either card as the winner and deleting the other would lose meaningful information. Cloud Contacts instead builds indexes for property collections already on the master, then moves or reconciles useful properties from each source while preserving the master's established values.

The merge covers more than the fields commonly shown on a compact contact card. It reconciles phone numbers, email addresses, postal addresses, organizations, instant-messaging addresses, websites, social profiles, custom dates, biographies, and extended properties. It fills missing name components, phonetic names, nicknames, birthdays, photos, and other scalar fields from sources when the survivor does not already contain a useful value. Notes from multiple cards are retained with a visible merged-note separator rather than silently overwriting one another.

Canonical property keys keep formatting variants from becoming redundant rows on the survivor. A property that represents the same phone, email, address, organization, website, or social identity can contribute useful ancillary details such as its label or primary flag without being copied as a second visually identical item. Deleted child-property tombstones are cleaned when their whole source contact is being retired, because an ownerless deletion marker cannot carry useful future synchronization intent. The goal is not merely fewer contact cards; it is fewer redundant properties on the card that remains.

No merge engine can manufacture a field that a provider never exported, and not every remote protocol represents every local property. Cloud Contacts preserves what exists in its data model and uses provider adapters to map supported fields. Proprietary contact APIs, CardDAV vCard, system address books, and JMAP ContactCard each have different capabilities and semantics. The app should report a provider limitation honestly rather than squeeze unknown data into an unrelated field. Local preservation and remote round-trip capability are connected, but they are not identical promises.

An address book becomes useful when it remembers context. A card may belong to Family, Emergency, Clients, School, or a provider-owned address book. It may participate in a household view, be linked as a parent or colleague, carry relationship history, appear in a birthday workflow, or be marked as a favorite. If duplicate cleanup preserves phone numbers but drops those connections, the resulting contact is technically smaller and practically worse.

Cloud Contacts moves provider account membership and group memberships from compatible source records onto the master when they are not already present. It also retargets contact links and relationship edges so references that pointed at a retired duplicate point at the survivor. Self-referential edges created by consolidation are removed rather than leaving a person related to itself. Shared and owned database relationships are handled according to their lifecycle so moving a value does not accidentally cascade-delete it with the source.

Recent-interaction information is preserved as well. If a duplicate source has a newer last-interaction date than the master, the survivor receives that newer value. Cleanup routines remove stale references to the retired object IDs from recap and recent-contact systems without removing the master that just inherited the history. Side effects occur after the database save, reducing the chance that an auxiliary index claims a deletion happened when the merge transaction actually failed.

For large operations, this is another reason to merge in bounded groups. Relationship rewiring can realize more objects than a simple phone comparison. A fresh context gives each small transaction a clear ownership boundary and allows its graph to disappear after save. The user experiences one durable identity; the implementation avoids keeping thousands of relationship-rich contacts alive together.

A common failure in contact cleaners is cosmetic merging. The app deletes a duplicate from its local list, but Google, Outlook, iCloud, a CardDAV server, or another source still owns the remote card. On the next synchronization, that card downloads again and the duplicate returns. The opposite failure is more dangerous: the app deletes a local object before recording which remote identity must be removed, so it no longer has enough information to send a correct provider deletion.

Cloud Contacts separates local-only and remote-backed source records. A local-only duplicate can be deleted from the local context after its useful data moves to the master. A remote-backed source with a real resource identifier is marked as deleting and receives a fresh update time. It remains available to the relevant sync engine as an explicit tombstone. The surviving master is marked dirty so its combined fields can be pushed where appropriate. Only after the provider confirms the requested lifecycle can the local synchronization state settle.

This is intentionally decoupled. Merge does not need to block on network availability, provider throttling, or an expired credential. The local transaction can finish while offline and leave truthful pending intent. A later two-way sync snapshots scalar request data in an isolated context, sends it through the provider adapter, and re-resolves object IDs to finalize success. Network callbacks do not retain or mutate live database objects. If a newer edit occurs while a request is in flight, the newer local intent remains dirty for a later pass rather than being mislabeled synchronized.

Provider boundaries still matter. A remote system may reject a field, require a new authentication, impose a request limit, or lack an equivalent for a custom property. Cloud Contacts can make the request retryable and report the error, but it cannot redefine an external API. This is why the public security model says changes go to providers the user explicitly connects, and why the article avoids promising that every property will round-trip through every service. Truthful synchronization is a state machine, not a claim that the network always succeeds.

A five-thousand-contact scan may take noticeably different time on different devices and databases. The interface should therefore communicate stages rather than freeze behind a spinner. Cloud Contacts exposes progress callbacks during scanning and merging. The UI can animate progress to show continuing work, but the animation is decoration around actual checkpoints; it is not a fabricated timer that reaches 100 percent regardless of database state. Stage labels can explain that the app is finding candidates, validating groups, combining contacts, or preparing synchronization.

Cancellation is checked between scan windows, object batches, groups, and merge source batches. When the user cancels, the worker stops scheduling new work at the next safe checkpoint. Already committed batches remain committed. Rolling them back would require one huge transaction—the very structure that bounded processing avoids—and could undo changes that the interface already reported as saved. Instead, the result records cancellation and the remaining group IDs, allowing the user to resume or scan again against the new durable state.

Failures are similarly specific. An incomplete detection fetch is discarded rather than published as if it represented the full address book. A failed merge group does not force unrelated successful groups to roll back. The final result includes merged-source counts, failed group indexes, and remaining IDs. User-facing language can then distinguish “completed,” “partly completed,” “cancelled,” and “needs attention.” That vocabulary protects trust: a person should never see “all fixed” when half the work remains.

Visual feedback matters on compact mobile interfaces in particular. A toolbar icon can be easy to miss, and expensive property counting can delay an action if the view waits for a pathological record. Cloud Contacts treats Fix as a real entrance with immediate tap feedback and diagnostic logging, then moves heavy analysis away from the main interface. If there are tens of thousands of redundant properties, the action should still acknowledge the tap, describe the stage, allow cancellation, and keep the user informed instead of appearing broken.

Live database objects are not ordinary thread-safe values. Each belongs to an isolated data context and that context's execution queue. Passing a live contact into an arbitrary background callback creates races that may appear only under a large dataset or slow network. Cloud Contacts uses separate contexts for scanning, merge writing, provider payload discovery, and remote finalization. Persistent object IDs and immutable scalar snapshots cross boundaries; live objects do not.

Duplicate detection is read-heavy and can use an isolated context pinned to a stable read snapshot. Merge mutation is write-heavy and runs through a dedicated serial queue so overlapping batches cannot fight over the same master. Provider adapters serialize or bound their own request paths according to protocol limits. Batch-oriented APIs use scalar request snapshots and bounded remote groups; CardDAV bounds concurrent downloads; photo work is separated so a whole account's binary images do not accumulate in memory. These are manifestations of one rule: the callback owns values, while a data context owns live objects.

The interface thread receives progress, final results, and merged-store notifications. It remains responsible for rendering buttons, lists, navigation, and cancellation input—not for normalizing every property or saving thousands of records. This division is how an animated progress bar can remain fluid during real work. It also improves accessibility: screen-reader announcements and button-state changes can occur promptly instead of waiting for a database loop to yield.

Concurrency does not eliminate contention. A sync can edit records after a scan, and the interface data context can hold an older snapshot. That is why each write batch re-resolves IDs, validates state, saves through an isolated transaction context, and then publishes saved object-ID changes to the visible state. The architecture assumes the world can change between discovery and mutation. It does not assume that one long operation owns the entire app.

“Is contact merging secure?” has several answers because security is not one switch. The duplicate scan and merge work against the app's local object store. The compact matching index needs normalized identity keys and object references, not photos, notes, or full addresses. Heavy processing occurs in isolated contexts on the device. That limits the data involved in each step and avoids uploading an address book merely to decide which local cards look alike.

Account authentication is a separate surface. Supported OAuth flows use provider authorization rather than asking the app to invent a provider password protocol. The operating system's secure credential store holds app passcodes and supported credentials or tokens under system access controls, keeping credential material separate from ordinary settings text. The app also offers passcode and device-biometric access controls so a person can restrict entry to the interface and protected-contact areas.

Those controls must be described accurately. An app lock is an access gate; it is not the same statement as encrypting every byte of the local database. Likewise, biometric verification is performed by the operating system; Cloud Contacts receives only an authentication result and does not receive or store a face or fingerprint template. Security copy should tell users what a feature actually protects and avoid turning several real controls into one exaggerated “military-grade” promise.

Remote synchronization is another explicit boundary. When a user connects a hosted provider, CardDAV, JMAP, a system address book, or another supported source, the chosen contact changes travel to that provider through its protocol. That is the purpose of sync. Transport security, certificate validation, provider authentication, request timeouts, and bounded payloads matter, but the provider's own storage and privacy rules also apply. Cloud Contacts should never say “nothing leaves your device” while offering remote synchronization. The honest statement is local-first processing with user-directed provider communication.

Cloud Contacts uses its local database as the primary working store. Duplicate detection and merging do not require Cloud Backup. A person can organize and synchronize provider records without creating an app-managed backup snapshot. If the person chooses Cloud Backup, signs in with a non-anonymous app account, and explicitly starts Backup Now, the app maps available contacts into a snapshot and uploads records to the hosted backup service under that authenticated account. Backup metadata includes the device name, time, and contact count so snapshots can be identified and restored.

This distinction matters because “cloud” appears in both the product name and the names of external providers. Provider sync means Cloud Contacts communicates with the provider that already owns or will own a contact. App-managed Cloud Backup means a separate snapshot is stored for restore. The user should be able to understand which operation is happening, see success or failure, review backup history, restore deliberately, and delete snapshots through the backup experience. Neither path should be disguised as purely local.

The public article does not call the current backup end-to-end encrypted. Transport and at-rest protections supplied by the hosted backup infrastructure are meaningful, but end-to-end encryption normally means the service cannot read plaintext because encryption and private-key control remain entirely at the endpoints. That is a stronger architecture claim and requires separately verified client-side cryptography and key lifecycle behavior. Marketing language should not borrow that phrase merely because a network connection and cloud storage use encryption.

Privacy also includes operational messages. A sync notification can say that an account finished and how many records changed without putting a contact's full name, email, street address, note, or raw provider error on the lock screen. Diagnostic logs should prefer record IDs, stage names, bounded counts, and sanitized error categories. If a user intentionally opens a detail screen, richer data is appropriate; background notifications and logs should follow data minimization.

A naive cleaner can look impressive in a demo. Fetch all contacts, touch every relationship, compare every pair, choose the first card, copy a few visible fields, delete the rest, and show a success alert. Each step is easy to write. Together, they create fragile behavior: memory spikes with object graphs, work grows quadratically, same-name people become false positives, provider identities disappear before remote deletion, one store error invalidates a giant transaction, and cancellation becomes impossible until the loop ends.

Cloud Contacts replaces that chain with explicit controls. Active IDs are snapshotted in stable order. Only identity relationships are prefetched for 25 contact graphs at a time. Normalized keys join through a representative index and union-find. Account domains constrain destructive grouping. Review and exact modes use different evidence. Approved groups carry object IDs into 25-source transactions with a stable master. Rich properties and relationship context are reconciled. Remote-backed sources become pending deletions. Progress follows saved checkpoints, and remaining IDs survive partial completion.

No single control makes the system perfect. A 25-object batch can still contain an exceptionally large graph. An exact shared household phone can still require human judgment. A provider can reject a request. The database can run out of storage. The process can be interrupted by the operating system. The value of layered design is that each condition has a smaller scope and a truthful result. The app can release a batch, skip an invalid group, preserve pending sync intent, or invite a retry without corrupting an unrelated part of the address book.

This is also why we publish the architecture. “Handles 5,000+ contacts” should not mean “we tried a big number once.” It should mean the normal execution path has identifiable bounds, the identity rules are explainable, mutation is staged, and privacy boundaries are documented. Public technical writing creates accountability: if future code changes the constants or lifecycle, the article and its source-of-truth brief should be revised rather than leaving an attractive but stale promise online.

Begin by checking which providers own your contacts. Cloud Contacts can show account or provider identity on contact rows, including multiple owners where relevant. If old hosted, CardDAV, or system-address-book sources are still connected, decide whether they should remain active before cleanup. Removing an account connection and deleting the remote address book are different actions; confirm the intended scope. If you use app-managed Cloud Backup, create a deliberate snapshot and wait for its recorded completion before starting a large merge.

Run duplicate review before broad automatic cleanup when the library contains families, shared office numbers, school contacts, or many common names. Inspect the proposed master and the primary non-redundant properties. Use the total Fix entrance when one card has an extreme number of repeated values, and use long-press copy if you want to preserve a specific property elsewhere. Similar-name suggestions deserve visual confirmation. Exact phone and email groups are stronger candidates, but shared endpoints can still justify a quick review.

During a long action, keep the app available when practical and watch the stage and progress messages. You can cancel if the device becomes warm, the result looks unexpected, or you need to leave. Cancellation stops at a safe checkpoint and may leave earlier batches completed. Read the final status instead of assuming Cancel means zero changes. If the result is partial, retry the remaining work or run a fresh scan; the new scan evaluates the current persistent state rather than an obsolete list.

After local cleanup, synchronize each connected provider and review the app's history messages. A completed local merge can still leave remote deletions or survivor updates pending while offline or unauthenticated. If a provider reports that credentials need attention, reconnect it and retry. Finally, spot-check several important contacts—family, emergency, business, and high-property records—in both Cloud Contacts and the provider's own interface. A careful five-minute review is a good exchange for reorganizing years of identity data.

A useful duplicate-detector test does more than create two identical cards. It places matching contacts on opposite sides of the 200-ID scan boundary and verifies that a transitive bridge still joins the group. It includes deleted contacts and deleted property tombstones and confirms they do not contribute keys. It creates accountless and differently scoped records and confirms they stay separate. It checks stable ordering so repeated runs do not produce arbitrary masters. These cases prove the architecture, not merely the comparison helper.

Merge tests should cover a source count greater than the 25-contact batch size, a photo-bearing master, fields distributed across different sources, notes, group membership, relationship rewiring, remote-backed deletion state, local-only deletion, validation changes between scan and write, cancellation after a committed batch, and a failure that leaves remaining IDs retryable. Memory tests are especially valuable when a contact has an abnormal property count, because average contacts do not reveal accidental relationship retention.

Provider tests need a separate matrix: create, update, delete, authentication expiry, timeout, throttling, partial remote success, missing response, local edit while a request is in flight, and pull reconciliation after an incomplete download. A provider sync should not mark a record clean until the matching remote result and local finalization succeed. Missing-remote reconciliation must not interpret a partial page as proof that every unseen card was deleted. Those state rules are what keep a local merge from being undone or amplified by a later sync.

Observability completes the loop. Logs can record stage, provider category, batch number, object-ID-safe references, duration, sanitized error type, and remaining counts without printing private contact content. User-facing history can summarize completed syncs, failed backups, merge results, and required authentication. App icon badge counts can point to unread operational messages when the user enables them. The purpose is not surveillance; it is to make the app truthful about long-running work and give support enough context to diagnose a failure without harvesting the address book.

It means the normal detector does not intentionally load all contact graphs and compare all possible pairs. It uses an ID snapshot, 200-ID outer windows, 25-contact inner graph fetches, compact scoped keys, and union-find grouping. It means the merge writer uses a stable master, 25-source transactions, isolated contexts, scoped memory-release boundaries, revalidation, progress, cancellation, and partial results. It means remote-backed sources retain provider deletion intent and the survivor remains available for later synchronization.

It does not mean every library of 5,000 contacts finishes in the same number of seconds. A database of mostly names and one phone is different from a database containing full-resolution photos, long notes, dense relationship graphs, or a damaged card with 131,000 repeated properties. Storage speed, available device memory, concurrent sync activity, thermal state, and provider response all change elapsed time. Cloud Contacts can constrain working sets and network requests; it cannot make different workloads identical.

It does not mean the app knows human identity perfectly. Two records can share a family phone or role address and still represent different people. Two records can belong to the same person and share no machine-comparable field. This is why exact and review modes exist, why provider account domains matter, and why important contacts deserve a spot-check. The app provides evidence and careful mutation; the user remains the authority on ambiguous identity.

It also does not mean contact data never leaves the device. Local duplicate analysis stays in the local working store, but remote sync sends data to connected providers and optional Cloud Backup stores an explicit snapshot in the hosted backup service. A trustworthy product can be local-first and cloud-capable at the same time if the boundaries are visible and controlled. Our promise is not mystery. It is that the architecture, choices, progress, and limitations are explainable.