Principal Retail Performance Architect — Peak Transaction Resilience

The mandate

Retail demand does not arrive as a smooth increase in identical requests. Campaign entry, catalogue browsing, inventory checks and checkout compete differently for constrained resources, while abandoned journeys and retries alter the load itself. This principal role will establish performance architecture for selected customer transactions so that launch decisions rest on realistic behaviour and failure evidence rather than a single headline throughput figure or a successful demonstration under an unrealistically clean test population.

The architect will trace journeys from arrival pattern through critical dependencies to the completed business transaction. A fast catalogue response is not sufficient if inventory reservation queues grow, and a completed payment callback is not equivalent to a confirmed order. Working with product and platform owners, the principal will define the measured boundaries, identify where apparently successful technical responses conceal incomplete journeys and make tail behaviour, error states and recovery visible alongside average response time.

Capacity recommendations need an explicit account of their assumptions. Traffic mix, session concurrency, data size, cache condition and dependency behaviour will be recorded so that a previous test can be replayed or its conclusion challenged. The role will examine whether a proposed mitigation removes the constrained work, merely moves it elsewhere or depends on a temporary condition. Engineering and commercial reviewers should be able to distinguish demonstrated capacity from extrapolation before committing to a campaign or release.

The principal leads the technical method used by six performance and platform engineers, including experiment design, analysis reviews and the interpretation of failed tests. Within the platform team's delegation, the architect sets performance evidence standards and recommends capacity actions or release restrictions. Product leadership accepts customer trade-offs, platform owners implement architecture changes and the authorised release owner decides deployment. The post does not control commercial campaign budgets, payment operations or the organisation's entire technology strategy.

During the first eighteen months, priority is to establish peak-demand baselines for three material journeys, test controlled degradation and introduce repeatable reviews before major demand events. Sustainable ownership follows: the principal maintains experiment quality, examines changes in customer behaviour and mentors engineers who can defend their findings. This is open-ended permanent employment, with continuing accountability for transaction performance after the initial agenda rather than a fixed appointment ending when the first peak season passes.

What you will own

• Define peak-demand journey models with product owners, recording arrival bursts, customer sequencing, abandoned attempts and retries that materially change the work imposed on the platform.
• Establish transaction-level measurement boundaries so inventory, checkout and order confirmation results show genuine completion, partial failure and delayed recovery rather than isolated service success.
• Design controlled experiments around suspected constraints, varying one meaningful condition at a time and preserving data that allows another engineer to reproduce the conclusion.
• Recommend capacity and degradation choices with documented confidence limits, identifying whether a change reduces constrained demand, increases sustainable supply or simply relocates the bottleneck.
• Review release performance evidence before major retail events, distinguishing a credible operational envelope from unsupported extrapolation and escalating unresolved customer-impact decisions to their owners.
• Mentor the six-engineer technical group through analysis critiques and experiment reviews, developing the ability to challenge misleading averages and explain contradictory observations constructively.
• Maintain a versioned peak-readiness record linking assumptions, test conditions, known constraints and owner decisions, so later changes can be compared with what was actually demonstrated.

Candidate qualifications

• Have at least seven years of relevant performance engineering or architectural experience, with direct analytical responsibility for a retail or comparable transaction journey. Explain a capacity conclusion you personally changed after examining workload behaviour rather than increasing test volume alone. Evidence should connect the technical measurement to the business transaction, including incomplete outcomes, conflicting indicators or a material assumption that had previously gone untested.
• Demonstrate sound experimental reasoning across concurrency, queuing, latency distributions, resource saturation and recovery. You should be able to describe the hypotheses considered, the controlled variations used and the limits of the result without assuming one particular tool or deployment stack. Show how you separated a repeatable platform constraint from a test-data defect, environmental limitation or dependency condition, and how another practitioner could validate your explanation.
• Bring practical familiarity with retail demand and transaction consistency, sufficient to challenge a peak test that models browsing well but neglects reservation, checkout or delayed confirmation. Product-specific implementation knowledge can be developed within the platform; what matters is understanding why workload mix and outcome definition change the conclusion. No commercial campaign ownership or specialist financial-services licence is required, and payment-policy decisions remain with their authorised owners.
• Show technical leadership through design reviews, mentoring, cross-team analysis or architecture recommendations that engineers actually used. Prior management of a large department is not a condition, but evidence must demonstrate clear judgement, accountable follow-through and respectful challenge when release pressure conflicts with the data. Be able to work in Hyderabad's hybrid engineering cadence and present decision-ready findings during scheduled platform reviews without hiding uncertainty behind a summary metric.

Application

Applications for this mandate are received in one way only: through the India Board Terminal's application process. It is automated end to end. Your Executive Passport travels to the mandate holder in its confidential form, your answers to the three questions below are read before anything else in your file, and every stage that follows is recorded on your applications page.

There is no address to write to and no intermediary to call. The mandate holder reads what the Terminal delivers and nothing else, which is what keeps the process the same for every applicant and keeps your name out of it until you release it. Applications close on 8 October 2026. Mandate reference CVU-PER-2026-IND-081.