Loyalty Points Redemption Service
Description 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…
Create a free account to upload your work. Your progress saves as a draft until you submit.
What You'll Be Doing
Description
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.
Constraints to Consider
- The
mv_member_points_balanceview 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. - The partner configuration service is read-only. You can read partner-specific redemption rules (minimum thresholds, blocked categories, point multipliers) but cannot modify the service or its schema.
- Scoped delivery: Scope your work to what stops the bleeding in 48 hours. Your README must distinguish the immediate fix from the two-week hardening work — and explain why you drew the line where you did.
- On-call ownership: Your team owns this service in production. Whatever you ship, you are on call for it at 2am. Design accordingly.
AI Usage Guidance
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).
What You'll Accomplish
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
How Your Work Will Be Scored
What to Submit
File 1 — Code Artifact: Points Redemption Service Fix
Format: no restrictions
Build a working proof-of-concept that resolves the root cause you identified. Your implementation must:
- Implement a corrected
PointsAvailabilityServicethat addresses the root cause — show the fix, not just a description of it - Handle upstream service failures gracefully: mock the member ledger, materialized view, and partner configuration service — we are evaluating service design, not integration
- Include at least one observability hook (structured logging, metrics emission, or health check endpoint) that would be useful in a production travel platform
- Use any language from arrivia's stack: TypeScript/JavaScript, Python, or C#/.NET
- Include both a backend service and a minimal frontend or CLI that demonstrates the redemption check end-to-end
Sign in to upload files
File 2 — README Document
Format: .pdf, .doc, .docx, .rtf, .txt, .md
Three required sections:
Section A — Diagnosis & Architecture (300–500 words)
- Diagnosis: What is the root cause? Trace the mechanism from deploy to failure — do not just name the symptom. Explain the specific sequence of events that produces the error in Data Point 2.
- Architecture decision: What did you change and why? What alternatives did you consider and reject, and why did you reject them given the constraints?
- Trade-offs: What did you deprioritize in the 48-hour fix? What would you address in the two-week hardening window, and why does it belong there rather than in the immediate fix?
Section B — Production Readiness & Monitoring Design
Part B1 — Monitoring design: Design the observability strategy for this service. What would you instrument to detect this class of failure before a member reports it? Name at least two specific metrics, their alert thresholds, and the rationale for each threshold value. How would your instrumentation distinguish this class of data consistency problem from an upstream service degradation or availability issue?
Part B2 — Required reasoning question (answer without AI assistance): Describe a specific scenario where an AI coding assistant would generate a plausible but incorrect solution for a data consistency bug of this type — particularly one involving a caching layer, a read replica, or a materialized view. What would the incorrect output look like? What would you check before acting on it?
Section C — AI Usage Log (Mandatory)
This is not a trick. We want to see how you work with AI — not whether you used it.
In a short section of your README, document your AI collaboration process. For each significant interaction with an AI tool, briefly note: what you asked the AI to help with / what it gave you / what you kept, changed, or rejected — and why.
Three interactions documented is sufficient. The log does not need to be exhaustive.
Sign in to upload files
File 3 — Video Walkthrough (8–10 minutes)
Format: .mp4, .mov, .webm
Record as MP4 or MOV and upload directly on the Provn platform as a separate file. Structure your video as follows:
- Summary (60 seconds): Root cause, your fix, and why the 48-hour scope is the right first step for this specific partner escalation.
- Code walkthrough (2–4 minutes): Walk through your implementation — how you corrected the points availability check, how you handle upstream failures, and one design decision you are most proud of.
- Section B walkthrough (1–3 minutes): Walk through your monitoring design — what you'd instrument, the thresholds you set, and how your observability strategy would surface this class of failure before a member reports it.
- Mandatory AI question (1–2 minutes): 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.
- Reflection (30–60 seconds): What would you change with more time? What would you validate before shipping this fix to production?
Speak naturally. Communication is assessed on clarity of technical ideas and logical structure — not verbal polish, accent, or filler words.
Sign in to upload files
Create a free account to upload your work. Your progress saves as a draft until you submit.
On this page