You are a full-stack engineer on arrivia's loyalty platform team. arrivia powers white-label travel booking portals for banks, financial institutions, and membership organizations worldwide. Partners integrate arrivia's booking engine, loyalty currency, and marketing tools into their own branded experiences — meaning arrivia operates a multi-tenant architecture where partner-specific configuration, branding, and redemption rules coexist on a shared platform.
Three days ago, your team shipped v2.3.2 of the Points Redemption Service. Since the deploy, 8% of redemption attempts are failing for one high-value bank partner (Partner BNK-0047, 2.1M active members). All other partners are unaffected. The partner's account team is escalating.
Your observability stack has surfaced three data points:
Data Point 1 — Error rate spike Since the v2.3.2 deploy, the Points Redemption Service is returning 'INSUFFICIENT_BALANCE' errors for ~8% of redemption attempts on BNK-0047. Other partners: normal error rates.
Data Point 2 — Sample error log
[ERROR] RedemptionValidation: member_id=7841203, partner=BNK-0047
Required: 15,000 pts | Available (service): 14,500 pts
Member portal shows: 18,700 pts
Timestamp: 2026-06-20T14:32:07Z
P99 latency, partner config calls: 45ms → 340ms (change: 3 days ago)
Data Point 3 — Deployment diff summary
v2.3.1 → v2.3.2
PointsAvailabilityService: changed points source from
live query on member_ledger (primary RDS read replica)
to
mv_member_points_balance (materialized view, refresh: every 15 min)
Rationale: reduce read load on primary ledger database
Read the provided data carefully — the service may have failure modes beyond the primary incident. Your task is to diagnose the root cause, build a proof-of-concept fix, and design the observability strategy that would have caught this before a member reported it.
mv_member_points_balance view is owned by the Data Platform team. You cannot modify its refresh schedule or definition. You decide whether and how to use it — but you cannot change it.We expect you to use AI tools. We evaluate how you use them — not whether you use them. Evidence of iteration, redirection, and critical evaluation scores higher than a polished output with no process documentation.
The single highest-signal indicator: your video answer to the mandatory AI question. If you cannot name a specific moment where you redirected AI output, evaluators will assume you did not.
Mandatory AI question for your video: Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you — and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why.
Speak naturally. Communication is assessed on clarity of technical ideas and logical structure — not verbal polish, accent, or filler words.
Submission: Upload each deliverable as a separate file directly on the Provn platform: your code artifact, your README document (Sections A, B, and C), and your video walkthrough (MP4 or MOV).
Demonstrate production-grade root cause diagnosis from real observability artifacts — error logs, latency metrics, and deployment diffs — without being handed the answer
Build a working proof-of-concept that fixes a data consistency failure in a multi-tenant financial platform, with observable error handling and graceful upstream failure recovery
Design a monitoring and alerting strategy for a loyalty transaction service, including specific metrics, thresholds, and the rationale for each
Show critical evaluation of AI coding assistance: identify where AI would generate plausible but incorrect solutions for data consistency problems, and explain how you catch the error
Demonstrate arrivia-context reasoning — decisions that reflect multi-tenant architecture, partner SLA awareness, and the financial sensitivity of loyalty point balances
Scope a realistic 48-hour emergency fix and a two-week hardening plan for a production service under active partner escalation
On this page