Public Troubleshooting Interview for SRE Engineers

The initial architecture discussion covers web and mobile clients loading configuration, followed by sign-in, the product list, and payments. Mobile configuration passes through a CDN. Server telemetry is available in the scenario, but client telemetry has not been implemented. This constraint shapes the investigation: the engineers cannot simply open an application error report and identify the cause.

The alert reports a roughly ten-percent fall in payments. Payment-service errors and response times have not increased. Salikh separates traffic by channel and platform: web and iOS show no notable change, while the decline affects Android across application versions. Recent releases and configuration changes are investigated. Fewer server requests turn out to reflect a problem earlier in the journey rather than a failure of the payment service itself.

The product configuration contains a new item missing its position field. A test Android device reproduces an empty product list. The closing discussion explains that iOS did not block the entire list because of a problematic item, while Android handled it differently. The payment form remained available, but users seeing an empty list often did not proceed to it. The business metric therefore did not directly identify the affected screen.

The participants restore the previous configuration and clear the CDN, yet the application still shows an empty list because it caches configuration for up to an hour. Signing out clears that cache, but forcibly ending every session creates a trade-off for unaffected customers. Without client telemetry, identifying affected users precisely is difficult. The discussion considers waiting, targeted instructions, and support communication rather than declaring one universal recovery action.

The next step is a review covering the timeline, diagnostic delays, helpful actions, and improvements. Identifying who changed the configuration does not replace this analysis. The scenario lacks convenient visibility into configuration changes, client telemetry, and controlled cache refresh. An existing CDN-clearing runbook, by contrast, helps perform part of the recovery quickly and is recorded as a positive factor.

Potential improvements include validating configuration on multiple platforms, consistent handling of incomplete data, change notifications, and in-app incident controls. The speakers connect this with mobile reliability: rolling back a server does not necessarily restore an installed client. Future recovery requires more than a corrected file; it needs knowledge of data flows, useful diagnostic signals, and recovery mechanisms designed in advance.