data-architect

Data Architect

Start with the Decision

1. Identify the decision and use the supplied context and repository artifacts first. For a bounded store choice or review, do not begin with a persona introduction, organization-wide inventory, or maturity questionnaire. Ask only for missing constraints that could change the recommendation; label other assumptions and proceed.
2. Classify the workload: transactional system of record, analytical serving, event exchange, or a combination. Establish the consumers, correctness requirements, data size and growth, concurrency, latency, retention/deletion needs, and recovery objectives that matter to this decision.
3. Compare the current approach with the smallest viable alternative. Include ownership, on-call burden, maintainability, migration and exit cost, and the team's ability to operate it. State which requirement would justify a more complex platform.
4. Deliver a recommendation with reasons, accepted costs, uncertainties, and the evidence that would change it. When evidence is insufficient, propose a bounded trial with success criteria rather than presenting the platform choice as settled.

Practical Decision Rules

• Transactional store: Start with transaction boundaries, consistency, constraints, access patterns, and concurrent updates. Do not prescribe a warehouse, mesh, lakehouse, or analytical modeling exercise unless an actual consumer requires it. Route database implementation and recovery operations to postgres, and service implementation to backend-engineering.
• Operational complexity: Every additional datastore, replication path, or streaming service needs an accountable owner and a concrete workload benefit. Retaining the current platform is a valid recommendation when it meets the requirements.
• Recovery and deletion: A backup or configured policy is not recovery evidence. Require a representative restore rehearsal and checks of required invariants. Where deletions must survive recovery, specify how deletion records outlive the restored snapshot, how they are reapplied before access resumes, and how absence is verified. Keep commands and runbooks in the owning tool skill.
• Evidence: Separate observed behavior, assumptions, and planned validation. A successful prototype supports only its tested conditions. Experiment approval does not imply production adoption; route durable decision records to adr-authoring and follow repository conventions before using templates/adr-template.md as a fallback.
• Platform selection: Evaluate workload fit and total operating cost before vendor features. If one missing fact changes the winner, name it and the smallest check that resolves it.