Keep Merchant Addresses, Social Followers, and Wiki Facts Up to Date

Design a system that can keep merchant information updated, including address, follower counts on social platforms, and founding year and country extracted from a wiki page. Explain how updates are collected, matched to the correct merchant, stored, and served. ### Constraints The desired freshness, merchant count, update triggers, and source permissions are not specified. Clarify whether updates are merchant-submitted, periodically collected, event-driven, or a combination. Preserve provenance for each field; do not assume that all external sources provide webhooks or identical APIs. ### Clarifying Questions - Which sources are authoritative for address, founding year, and country when they disagree? - How are a merchant's social accounts and wiki page verified? - What does timely updating mean for each field, and how should stale data be displayed? - Are follower counts snapshots per platform, and how should unavailable accounts be represented? ```hint Give each value a source and time A newer fetch is not necessarily a newer fact, and a missing response is not a follower count of zero. ``` ### What a Strong Answer Covers - Merchant identity, field-level provenance, conflict policy, and timestamps. - Source-specific collectors, rate limits, retries, change detection, and freshness scheduling. - Validation of extracted founding facts, partial failures, and serving reliable current views. ### Follow-up Questions - How would you prevent a wiki-page redirect from assigning facts to the wrong merchant? - How would collection continue when one social platform becomes unavailable?