21 Microsoft Php Developer Interview Questions & Answers

1. Return the top K most frequent error codes from log lines.CodingEasyMicrosoft

Question Details

Given log lines containing an error-code string, return the K most frequent error codes. Sort by descending frequency and, for ties, by ascending error-code value. Explain edge cases and complexity.

Short Interview Answer (30-60 seconds)

I would count each error code with a PHP associative array, where the code is the key and its frequency is the value. Then I would collect the unique codes and sort them by frequency in descending order. If two codes have the same frequency, I would sort them by ascending code value. Finally, I return the first K codes. The expected time is O(n + m log m), and the auxiliary space is O(m).

Detailed Explanation

See the Code while reading this explanation.

The input is a list of error-code strings and a number K. We must return the K codes that appear most often. A code with a larger count comes first. When two codes have the same count, the smaller code in ascending text order comes first. We first count each code, then sort only the unique codes, and finally return the first K results.

Useful Questions to Ask the Interviewer

Can the input array be empty?
What should happen when K is zero or negative?
Can K be greater than the number of unique error codes?
Are error codes always strings?
Should error-code comparison be case-sensitive?

Return the top K most frequent error codes from log lines. diagram

How to Explain It in an Interview

1. Understand the input and required output

The input is an array of error-code strings and an integer K. The output contains error-code values, not indices. The codes must be ordered by descending frequency. If two codes have the same frequency, they must be ordered by ascending code value.

The example is: logLines = ["E500", "E404", "E500", "E401", "E404", "E500", "E401"] K = 2

The expected output is: ["E500", "E401"]

2. Choose the algorithm and data structure

I use a PHP associative array as a frequency map. Each key is an error code. Each value is the number of times that code has appeared.

The central invariant is: after processing the first i log lines, the frequency map stores the exact count of every code in those i lines.

After counting, I sort only the unique codes. The comparator first compares their frequencies. A code with a larger frequency comes first. If the frequencies are equal, strcmp places the smaller code value first.

3. Initialize the state

The frequency map starts empty: $freq = []

Traversal begins at index 0. For each code, the algorithm increases its stored count by one. If the code is not yet in the map, its previous count is treated as zero.

4. Walk through the example

At index 0, the current code is E500. The map changes from {} to {E500:1}.

At index 1, the current code is E404. The map changes from {E500:1} to {E500:1, E404:1}.

At index 2, the current code is E500. Its count increases, so the map becomes {E500:2, E404:1}.

At index 3, the current code is E401. The map becomes {E500:2, E404:1, E401:1}.

At index 4, the current code is E404. The map becomes {E500:2, E404:2, E401:1}.

At index 5, the current code is E500. The map becomes {E500:3, E404:2, E401:1}.

At index 6, the current code is E401. The final map becomes {E500:3, E404:2, E401:2}.

The unique codes are [E500, E404, E401]. Sorting by descending frequency puts E500 first because its count is 3. E404 and E401 both have count 2. The tie is broken by ascending code value, so E401 comes before E404. The sorted order is [E500, E401, E404]. Taking the first two codes returns [E500, E401].

5. Explain why the result is correct

The frequency map stores the exact count of every code. The comparator follows the required ordering rule. It places larger frequencies first and uses ascending code order for equal frequencies. Therefore, after sorting, the first K codes are exactly the required answer.

6. Explain the PHP implementation

The function first returns an empty array when K is zero or negative. It then builds the frequency map with one pass through the input. Next, array_keys creates the list of unique codes. usort applies the required comparator. Finally, array_slice returns the first K codes. If K is larger than the number of unique codes, array_slice returns all available codes.

7. Explain complexity and edge cases

Let n be the number of log lines and m be the number of unique error codes. Counting takes O(n) expected time because PHP associative-array lookup and insertion are O(1) on average. Sorting the m unique codes takes O(m log m) time. The total expected time is O(n + m log m). The auxiliary space is O(m).

Important edge cases are an empty input, K less than or equal to zero, duplicate codes, equal frequencies, and K greater than the number of unique codes.

Key Insight / Why This Solution Works

The key idea is to separate counting from ranking. First, build a frequency map where each key is an error code and each value is its exact count. Then sort only the unique codes. The comparator places the code with the larger count first. When two counts are equal, it compares the code strings in ascending order. The central invariant is that after processing any prefix of the input, the map contains the exact frequency of every code in that prefix. Because the final counts are correct and the comparator matches the required order, taking the first K codes returns the correct result.

Code

<?php

declare(strict_types=1);

/**
 * Return the K most frequent error codes.
 *
 * Ordering rules:
 * 1. Higher frequency comes first.
 * 2. Equal frequencies use ascending error-code order.
 *
 * @param string[] $logLines
 * @return string[]
 */
function topKFrequentErrorCodes(array $logLines, int $k): array
{
    // Step 1: Handle a non-positive K.
    if ($k <= 0) {
        return [];
    }

    // Step 2: Build the frequency map.
    // Key: error code
    // Value: number of times the code appears
    $freq = [];

    foreach ($logLines as $code) {
        $freq[$code] = ($freq[$code] ?? 0) + 1;
    }

    // Step 3: Collect each unique error code once.
    $codes = array_keys($freq);

    // Step 4: Sort by descending frequency.
    // For equal frequencies, sort by ascending code value.
    usort(
        $codes,
        function (string $a, string $b) use ($freq): int {
            if ($freq[$a] === $freq[$b]) {
                return strcmp($a, $b);
            }

            return $freq[$b] <=> $freq[$a];
        }
    );

    // Step 5: Return the first K codes.
    // If K is larger than the number of unique codes,
    // array_slice returns all available codes.
    return array_slice($codes, 0, $k);
}

// Example from the diagram.
$logLines = ["E500", "E404", "E500", "E401", "E404", "E500", "E401"];
$k = 2;

$result = topKFrequentErrorCodes($logLines, $k);

echo json_encode($result, JSON_THROW_ON_ERROR) . PHP_EOL;

// Expected output:
// ["E500","E401"]

Time & Space Complexity

Let n be the number of log lines. Let m be the number of unique error codes. Building the frequency map takes O(n) expected time because PHP associative-array lookup and insertion are O(1) on average. Sorting the m unique codes takes O(m log m) time. Therefore, the total expected time is O(n + m log m). The frequency map and the unique-code array both grow with m, so the auxiliary space is O(m).

Where it is used

This pattern is useful in log analysis, monitoring dashboards, incident reports, API error summaries, and security systems. It can rank the most common error codes, warning types, exception names, event types, or status values. The same count-then-sort method also works for popular search terms, repeated user actions, and frequently requested resources.

Why Interviewers Ask This

This question checks whether the candidate can combine frequency counting with custom sorting. The interviewer is evaluating associative-array usage in PHP, duplicate handling, comparator design, tie-breaking, and accurate complexity analysis. It also tests whether the candidate distinguishes the total number of log lines from the number of unique codes and remembers to include the sorting cost.

Common interview mistakes

Common mistakes include sorting only by frequency and forgetting the ascending code-value rule for ties. Another mistake is sorting the full input instead of counting first and sorting only the unique codes. Candidates may reverse the spaceship comparison and place smaller frequencies first. They may also ignore the O(m log m) sorting cost and incorrectly claim O(n) total time. Other errors include mishandling duplicate codes or returning more than K results.

Interview tip

State the comparator rule before coding it: larger frequency first, then smaller code string first. This makes the usort logic easier to verify and helps prevent reversing either ordering condition.

Interviewer may ask next

How would the solution change if the log lines arrived as a continuous stream?

The same frequency map can be updated whenever a new code arrives, using O(1) expected time per update. When the current top K result is requested, the unique codes can be sorted with the same comparator. That query takes O(m log m) time and O(m) auxiliary space. This keeps the logic simple, but repeated queries may be expensive when m is large.

Can the ranking work be reduced when K is much smaller than the number of unique codes?

Yes. After building the same frequency map, a size-K heap can keep only the strongest K candidates. This changes the ranking work from O(m log m) to O(m log K). Counting still takes O(n) expected time. The frequency map uses O(m) space and the heap uses O(K) additional space. The tradeoff is more complex comparison logic, especially for the ascending code-value tie rule.

2. Reverse the nodes of a linked list in groups of K.CodingHardMicrosoft

Question Details

Given a singly linked list and an integer K, reverse nodes K at a time and return the modified list. Nodes in a final group smaller than K remain unchanged. Explain pointer safety, edge cases, and complexity.

Short Interview Answer (30-60 seconds)

I would reverse the linked list in groups of K using a dummy node and a few pointers. I first check whether a full group exists. If it does, I reverse only that group in place, then reconnect it to the already processed part and the rest of the list. If fewer than K nodes remain, I stop and leave them unchanged. This runs in O(n) time and O(1) extra space.

Detailed Explanation

See the Code while reading this explanation.

This question asks me to take a chain of items and turn every full group of K items around. The last group stays the same if it has fewer than K items. I do not build a new chain. I only change the links between the existing nodes. The diagram shows a dummy node, a pointer before the group, and a pointer that finds the end of each group. That keeps the rewiring safe and easy to explain.

Useful Questions to Ask the Interviewer

Is the last group smaller than K supposed to stay unchanged?
Should I change the list in place?
Can I assume K is at least 1?

Reverse the nodes of a linked list in groups of K. diagram

How to Explain It in an Interview

1. Understand the input and output

The input is a singly linked list and an integer K. The output is the same list, but every full group of K nodes is reversed. If the last group has fewer than K nodes, it stays in the same order.

2. Choose the algorithm and data structure

The diagram uses pointer rewiring with a dummy node. The dummy node makes head changes safe. groupPrev marks the node before the current group. kth finds the end of the group. The key idea is that the part before groupPrev is already correct.

3. Initialize the state

Start with a dummy node that points to the head. Set groupPrev to the dummy node. This is correct because nothing has been changed yet, and the full list is still in its original order.

4. Walk through the example

The example is 1 -> 2 -> 3 -> 4 -> 5 with K = 2.

First, the algorithm finds the group 1 and 2. It reverses them into 2 -> 1. Then it connects that group back to 3.

Next, it finds the group 3 and 4. It reverses them into 4 -> 3. Then it connects that group back to 5.

One node remains at the end. That node is smaller than K, so it is left unchanged. The final list is 2 -> 1 -> 4 -> 3 -> 5.

5. Explain why the result is correct

The invariant is simple. Every node before groupPrev is already in the final correct order. We only reverse one full group at a time. After the reverse, we reconnect the group to the already processed part and to the remaining part. That keeps the list valid after every step.

6. Explain the PHP implementation

The PHP code first handles the easy cases. If the list is empty or K is 1, it returns the head right away. Then it creates the dummy node. For each group, it finds kth from groupPrev. If there are fewer than K nodes left, it stops.

If a full group exists, the code stores groupNext, which is the node after the group. Then it reverses the links inside the group with prev, curr, and next. After that, it reconnects the reversed group by changing groupPrev->next and moving groupPrev to the tail of the reversed group.

7. Explain complexity and edge cases

The time is O(n) because each node is processed a constant number of times. The extra space is O(1) because we only use a few pointers and one dummy node. Important edge cases are K = 1, K bigger than the list length, an empty list, a single node list, and a list whose length is an exact multiple of K.

Key Insight / Why This Solution Works

The main idea is to reverse one full group at a time and keep the rest of the list safe with pointers.

The dummy node is important because it makes head changes easy. groupPrev always points to the node before the group we are working on. The kth pointer checks whether a full group exists. If fewer than K nodes remain, the algorithm stops.

The central invariant is: every node before groupPrev is already correct, and the current group is the only part being changed. We reverse only the links inside that group, then reconnect the reversed group back to the unchanged part of the list. That is why the result stays correct after each step.

Code

<?php

class ListNode {
    public int $val;
    public ?ListNode $next;

    public function __construct(int $val = 0, ?ListNode $next = null) {
        $this->val = $val;
        $this->next = $next;
    }
}

function reverseKGroup(?ListNode $head, int $k): ?ListNode {
    if ($head === null || $k <= 1) {
        return $head;
    }

    // Dummy node makes head changes safe.
    $dummy = new ListNode(0, $head);
    $groupPrev = $dummy;

    while (true) {
        // Find the kth node from groupPrev.
        $kth = $groupPrev;
        for ($i = 0; $i < $k && $kth !== null; $i++) {
            $kth = $kth->next;
        }

        // Stop when fewer than K nodes remain.
        if ($kth === null) {
            break;
        }

        // Save the node after the current group.
        $groupNext = $kth->next;

        // Reverse the current group in place.
        $prev = $groupNext;
        $curr = $groupPrev->next;

        while ($curr !== $groupNext) {
            $next = $curr->next;
            $curr->next = $prev;
            $prev = $curr;
            $curr = $next;
        }

        // Reconnect the reversed group.
        $tmp = $groupPrev->next;
        $groupPrev->next = $kth;
        $groupPrev = $tmp;
    }

    return $dummy->next;
}

function buildList(array $values): ?ListNode {
    $dummy = new ListNode();
    $tail = $dummy;

    foreach ($values as $value) {
        $tail->next = new ListNode((int)$value);
        $tail = $tail->next;
    }

    return $dummy->next;
}

function listToString(?ListNode $head): string {
    $parts = [];
    while ($head !== null) {
        $parts[] = (string)$head->val;
        $head = $head->next;
    }
    return implode(' -> ', $parts);
}

// Example run from the diagram.
// Input: 1 -> 2 -> 3 -> 4 -> 5, K = 2
// Output: 2 -> 1 -> 4 -> 3 -> 5
if (PHP_SAPI === 'cli' && basename(FILE) === basename($_SERVER['SCRIPT_FILENAME'])) {
    $head = buildList([1, 2, 3, 4, 5]);
    $result = reverseKGroup($head, 2);
    echo listToString($result) . PHP_EOL;
}

Time & Space Complexity

We move through the list group by group. Each node is touched only a constant number of times, so the total time is O(n).

The extra memory is O(1). We only use a few pointers and one dummy node. We do not build another list. We do not use a stack or a map.

For the diagram example, the list 1 -> 2 -> 3 -> 4 -> 5 with K = 2 becomes 2 -> 1 -> 4 -> 3 -> 5.

Where it is used

This pattern is useful when we need to change a linked list in place. A common use is batch reversal. Another use is interview practice for pointer safety, head changes, and list rewiring. It is also useful when memory use must stay low and we do not want to copy nodes.

Why Interviewers Ask This

Interviewers want to see if you can manage pointers safely, handle the group boundary correctly, and keep the head stable when it changes. They also want to know if you can stop at the right time when fewer than K nodes remain. This problem checks in-place list work, careful state updates, and clear complexity reasoning in PHP.

Common interview mistakes

Forgetting the dummy node. That makes head changes harder and can break the first group.

Reversing a partial group. The diagram says to stop when fewer than K nodes remain. That part must stay unchanged.

Losing the rest of the list while rewiring pointers. You must save next before changing curr->next.

Moving groupPrev to the wrong node after the reverse. It must move to the tail of the reversed group.

Claiming the wrong complexity. This solution is O(n) time and O(1) extra space.

Interview tip

Say the invariant out loud. The nodes before groupPrev are already correct, and only the current full group is being rewired.

Interviewer may ask next

What changes if K is 1 or the list has fewer than K nodes?

The function should return the original head right away. No reversal is needed because there is no full group to change.

How would the solution change if you wanted a recursive version instead?

You would still reverse one full group and then call the function on the rest of the list. The logic stays correct, but the recursion stack adds O(n) extra space in the worst case.

3. Design a search API for finding nearby service providers.API DesignHardMicrosoft

Question Details

Design an API for a query such as "plumbers near Kondapur." Cover request and response contracts, geospatial and text filters, pagination, ranking and personalization inputs, validation, errors, and compatibility with indexed and semantic retrieval.

Short Interview Answer (30-60 seconds)

At a high level, I would build one search API that finds relevant nearby service providers from text and location inputs. The client sends an HTTPS request with a JWT through the API Gateway to the Search API. The system validates the request, understands the service and place, searches indexed and semantic data, merges duplicates, ranks candidates, and paginates the response. The gateway handles authentication and rate limiting. The main trade-off is improved search quality and personalization at the cost of more latency and operational complexity.

Detailed Explanation

This API helps a person find a suitable local service provider. For example, the person may search for plumbers near Kondapur. The system must understand the requested service and search area. It must find matching providers, remove repeated results, and place the best choices first. It should also support useful filters, safe pagination, and clear errors. The explanation below follows the approved diagram from the client request through retrieval, ranking, and the final response.

Useful Questions to Ask the Interviewer

What is the maximum supported search radius?
Which text and location filters are required initially?
Should ranking favor distance, relevance, rating, or availability?
How fresh must provider availability information be?

Design a search API for finding nearby service providers. diagram

How to Explain It in an Interview

1. Start with the request contract and API boundary

I would expose GET /v1/search/providers through the Search API Endpoint. The diagram shows this example request: GET /v1/search/providers?q=plumbers&near=Kondapur&lat=17.47&lng=78.36&radiusKm=10&page=1&pageSize=20&sort=bestMatch.

The client sends the request over HTTPS with a JWT. A JWT is a signed token that identifies the caller. The API Gateway and Auth component validates the token, applies rate limiting, and forwards a verified request to the Search API Endpoint. The client is outside the Search Platform Boundary. The main search components are inside that boundary.

2. Validate and normalize the request

The Search API sends the request parameters to Query Validation and Normalization. This component sanitizes the query, checks the radius limit, checks the maximum page size, and accepts only allowlisted filters.

The supported text filters shown in the diagram include category, service type, keyword, rating, price tier, availability, and languages. The geographic filters include a place or coordinates and radiusKm.

Invalid parameters follow the error path to the Fallback and Error Handler. The diagram shows 400 for a bad request, 401 for missing or invalid authentication, 429 when the rate limit is exceeded, and 500 for an unexpected internal error.

3. Understand the service and resolve the place

The normalized query moves to the Query Understanding and Intent Parser. It extracts the service intent, such as plumbers, and the location, such as Kondapur. It may also identify optional price, rating, availability, or openNow filters.

The Intent Parser sends the place text to the Geocoder or Geo Resolver. The geocoder converts Kondapur into coordinates and returns 17.47, 78.36 to the query-processing flow. These coordinates allow the system to apply the requested search radius and geographic filtering.

4. Run indexed and semantic retrieval

The validated query is sent to two retrieval paths. Indexed Retrieval uses an inverted index over provider names, services, categories, locations, and keywords. This path is effective for direct text matches.

Semantic Retrieval uses vector representations of meaning. It can find synonyms and natural-language matches even when the provider data does not contain the exact query words.

Indexed Retrieval returns text candidates. Semantic Retrieval returns semantic candidates. Candidate Merge and Dedup combines both result sets and removes repeated providers before ranking.

5. Rank and personalize the candidates

The merged candidates move to Ranking and Personalization. The ranking signals shown in the diagram include distance, text relevance, semantic relevance, rating, availability, response time, price tier, sponsored boost, and user preferences.

The ranking component requests provider metadata and availability from the Provider Profile Store and Availability Store. That store returns provider signals. It also requests preferences from the User Profile, Preferences, and History store. That store returns personalization signals.

Keeping retrieval and ranking separate makes the design easier to change. Search indexes can focus on finding candidates, while ranking rules decide their final order.

6. Build and return the response

The ranked results move to Pagination and Response Builder. This component applies pagination and creates the JSON payload. The response contract contains items[], nextPageToken, totalApprox, appliedFilters, and an optional errors field.

The JSON payload returns to the Search API Endpoint. The Search API sends the JSON response to the API Gateway. The gateway then returns it to the Client App or Web App.

The API Gateway sends access logs to Logging and Analytics. The Search API sends query logs there. Logging supports monitoring and analysis, but it does not own or modify the business response.

Practical Complexity & Trade-offs

The benefit of this design is that each component has one clear job. Validation protects the platform from bad input. Indexed retrieval provides fast direct matches. Semantic retrieval improves results for synonyms and natural language. Ranking can combine distance, relevance, rating, availability, and preferences. The downside is that each extra processing step may increase response time. Personalization also depends on additional user data and can make ranking harder to explain. Pagination keeps responses smaller, but the client must follow nextPageToken to continue. The gateway improves protection through JWT validation and rate limiting, but it adds another service to operate. We accept this complexity because nearby search needs both location accuracy and strong relevance.

Why Interviewers Ask This

Interviewers use this question to test whether a candidate can define a clear API contract and trace request and response directions correctly. They evaluate input validation, authentication, rate limiting, filtering, pagination, ranking, and error handling. They also want to see whether the candidate understands why indexed and semantic retrieval may work together. A strong answer explains component ownership, data flow, failure paths, personalization, scalability concerns, and the trade-off between better search quality and added latency.

Interviewer may ask next

How would this design handle ten times more search traffic?

I would keep the same public endpoint and request contract, but scale the busiest search components independently. The client would still call GET /v1/search/providers, and the request would still pass through the API Gateway and Search API Endpoint.

I would first use Logging and Analytics to measure latency and traffic at each stage. Indexed Retrieval may need additional index capacity or partitions. Semantic Retrieval may need more vector-search capacity. Candidate Merge, Ranking and Personalization, and Pagination and Response Builder may need more service instances. The Provider Profile Store and User Profile Store must also support the increased read load while returning current signals.

The API Gateway would continue validating JWTs and enforcing rate limits. This protects the platform during sudden traffic spikes. The request, response, and error contracts would remain unchanged.

The main downside is higher operating cost. More distributed capacity can also make updates and troubleshooting harder, especially when indexed and semantic data are refreshed at different times.

What should happen when Kondapur cannot be resolved to one clear location?

I would stop the search before retrieval and return a clear validation error. The Query Understanding and Intent Parser sends Kondapur to the Geocoder or Geo Resolver. When the geocoder cannot return reliable coordinates, the query-processing flow does not have a safe geographic filter.

The failure should follow the existing Fallback and Error Handler path. The Search API should return 400 because the location input cannot be used as supplied. The response can use the existing optional errors field to explain that the location is missing, invalid, or ambiguous. The client can then ask the user for a more specific place or send latitude and longitude.

The API Gateway still performs JWT validation and rate limiting. Logging and Analytics records the failed request and its query context. Indexed Retrieval, Semantic Retrieval, Candidate Merge, and Ranking are not called because they could return providers from the wrong area.

The downside is that some uncommon but valid place names may require more user input. This is safer than silently searching an incorrect location.

4. Design a secure API for an enterprise AI copilot.API DesignHardMicrosoft

Question Details

Design a secure API for a multi-tenant enterprise AI copilot where authenticated users submit prompts. Define endpoints, tenant isolation, authentication, authorization, request validation, streaming or asynchronous responses, rate limits, auditability, errors, and idempotency.

Short Interview Answer (30-60 seconds)

At a high level, I would put a secure Copilot API Gateway in front of the AI workflow. The user signs in through the Enterprise IdP, then sends POST /v1/prompts over HTTPS with a JWT and an idempotency key. The gateway checks identity, permissions, tenant context, rate limits, and request shape. The Copilot Orchestrator applies prompt safety, reads tenant-scoped knowledge, calls the LLM, and sends tokens to the streaming channel. Long tasks use the async queue and job store. The trade-off is stronger isolation and auditability at the cost of more components and latency.

Detailed Explanation

We need a safe service that lets company users ask an AI assistant questions. Each company must only reach its own information. The service must reject users without permission, invalid requests, repeated submissions, and excessive traffic. Fast answers may arrive gradually. Longer tasks may continue after the first request ends. The design must also record important activity and return useful errors. I will explain the same path shown in the diagram, from user login through the AI response and supporting job, audit, and failure flows.

Useful Questions to Ask the Interviewer

How many tenants and users must the system support?
Which prompts should stream, and which should become background jobs?
What rate limits and response-time goals are required?
How long should job results and audit records be retained?

Design a secure API for an enterprise AI copilot. diagram

How to Explain It in an Interview

1. Authenticate the user

I would begin with the Enterprise Boundary. The Authenticated User or Client App signs in through the Enterprise IdP using OIDC. OIDC is a standard login process. The Enterprise IdP returns a JWT access token. A JWT is a signed token that carries the user identity and access information.

The client sends POST /v1/prompts to the Copilot API Gateway. The request uses HTTPS, the JWT, and an Idempotency-Key. HTTPS protects data in transit. The idempotency key lets the gateway recognize a repeated submission without claiming exactly-once processing.

2. Protect the API boundary

The Copilot API Gateway owns the main request checks. It performs JWT authentication, rate limiting, schema validation, idempotency handling, and tenant resolution.

The gateway asks the Authorization or Policy Engine to authorize the request. The policy engine checks RBAC, scopes, and tenant access. RBAC means permissions are linked to roles. It returns an allow or deny decision to the gateway.

The tenant resolver attaches the correct tenant context. This context must stay with the request so one tenant cannot access another tenant’s data.

3. Validate and process the prompt

After all checks pass, the gateway sends the validated request and tenant context to the Copilot Orchestrator. The orchestrator owns prompt handling.

The orchestrator sends the prompt to the Prompt Safety Filter for screening. The filter returns a safe prompt. The orchestrator then performs a tenant search against the Tenant Knowledge Store. The request includes the tenant_id, and the store returns tenant-scoped grounding data. Grounding data is trusted company information used to improve the answer.

The orchestrator sends the prompt and context to the external LLM Service. The LLM Service returns model output to the orchestrator.

4. Stream the response

For an interactive answer, the orchestrator sends a token stream to the Streaming Channel. The diagram shows that this channel supports SSE or WebSocket.

SSE sends server updates over a long HTTP response. WebSocket supports a longer two-way connection. Streaming improves perceived speed because output can be delivered gradually. The downside is more connection handling and more care around partial responses.

5. Handle long-running jobs

A long task follows the asynchronous path. The Copilot API Gateway places the task in the Async Job Queue. The queue creates a job in the Job Store.

The gateway returns 202 Accepted with a job_id. This means the request was accepted but is not complete. The client later sends GET /v1/jobs/{id} over HTTPS with its JWT. The gateway returns the job status or result with 200 OK, as shown in the diagram. Tenant context and authorization still apply to this lookup.

6. Record activity and return failures

The gateway sends request audit information to the Audit Log. The orchestrator sends prompt audit information there as well. The Audit Log forwards security events to SIEM or Monitoring. A SIEM collects security activity for investigation and alerting.

Authentication, authorization, validation, and rate-limit failures go through the Error Handler. It returns a 4xx or 5xx response with a request_id. The request ID helps operators trace the failure. Audit logging remains separate from the business response path.

7. Explain the trade-off

This design gives clear security ownership, tenant isolation, prompt safety, streaming, asynchronous processing, and auditability. The cost is additional latency and operational work. Each gateway check, policy call, queue, store, and logging path adds complexity. For an enterprise copilot handling private company data, that cost is reasonable.

Practical Complexity & Trade-offs

The benefit of this design is that each responsibility has a clear owner. The gateway checks identity, request shape, tenant context, rate limits, and repeated submissions before the prompt reaches the AI workflow. The policy engine keeps authorization separate from authentication. The tenant-scoped knowledge store lowers the risk of data crossing between companies. Streaming makes answers feel faster, while the async queue supports longer work. The downside is more operational complexity. Security checks add latency. Queues and job stores need monitoring and retention rules. Streaming connections need careful lifecycle handling. Audit records also need protection and storage. Idempotency reduces duplicate work, but it does not guarantee exactly-once processing. We accept these costs because isolation, traceability, and controlled access matter more than using the smallest possible architecture.

Why Interviewers Ask This

Interviewers ask this question to test engineering judgment, not memorized endpoint names. They want to see whether the candidate separates authentication from authorization, protects tenant data, validates requests, controls traffic, and models both streaming and background work. They also evaluate correct request and response directions, useful error handling, idempotency, audit ownership, and practical trade-offs. A strong answer explains why each control exists without claiming perfect security, exactly-once processing, or unlimited scale.

Interviewer may ask next

How would this design handle a large increase in long-running prompt requests?

I would keep the same API contract and send a larger share of long tasks through the existing asynchronous path. The affected endpoint is POST /v1/prompts. The Copilot API Gateway would still authenticate the JWT, resolve the tenant, apply rate limits, validate the request, check the idempotency key, and obtain an authorization decision before accepting the task.

The gateway would enqueue the validated task in the Async Job Queue. The queue would continue creating records in the Job Store. The client would receive 202 Accepted with a job_id and would continue polling GET /v1/jobs/{id} for status or results. Authorization and tenant context must be checked on every poll.

Capacity can be increased around the gateway, queue-processing path, orchestrator, and job store without changing the public endpoints. Monitoring should watch queue depth, job age, and failures. The main downside is longer completion time during heavy demand. The queue protects the synchronous API, but it does not remove the need for capacity planning or tenant-aware rate limits.

What should happen when the external LLM Service does not return model output?

The request should fail without bypassing any earlier security or tenant checks. The affected flow is the call from the Copilot Orchestrator to the external LLM Service. Authentication, authorization, tenant resolution, schema validation, idempotency handling, prompt safety, and tenant-scoped knowledge retrieval remain unchanged.

Without model output, the orchestrator cannot complete the normal response. The failure should use the existing Error Handler path and return a 5xx response with a request_id. For a streaming operation, the Streaming Channel must not present the response as successfully completed. For an asynchronous operation, the client should receive the job status or result through the existing GET /v1/jobs/{id} flow rather than a false successful answer.

The request and prompt activity should still be recorded in the Audit Log, and relevant security or operational events can reach SIEM or Monitoring. The diagram does not show retries or a second model provider, so I would not promise either. The downside is reduced availability when the external provider fails.

5. Design a low-latency product-price update API.API DesignHardMicrosoft

Question Details

Design an API and serving path for product prices that change at most once per day but must be returned with low latency on product-launch pages. Define update and read endpoints, validation, caching, freshness, versioning, errors, and consistency behavior.

Short Interview Answer (30-60 seconds)

At a high level, I would separate price updates from price reads. The admin tool uses PUT /v1/products/{id}/price through the API Gateway and Auth layer. The Price Update API validates and deduplicates the request, writes to the Primary Price Store, and publishes a price-updated event. That event refreshes the cache and updates the read model asynchronously. Product pages use GET /v1/products/{id}/price. The Price Read API serves cache hits quickly and falls back to the read model. The trade-off is low latency with brief, detectable stale reads.

Detailed Explanation

We need to store product prices safely and return them very quickly. A price changes at most once each day, but a product-launch page may receive heavy traffic. The main challenge is keeping reads fast while showing whether a price is fresh. The design uses one flow for updates and another flow for reads. The Primary Price Store keeps the official value. A distributed cache serves most customer requests. A version and updatedAt value help clients recognize older data.

Useful Questions to Ask the Interviewer

How much traffic should the product-launch page handle?
How long may a price remain slightly out of date?
Which users are allowed to update prices?
What fields must be validated in an update?
How should repeated update requests be handled?

Design a low-latency product-price update API. diagram

How to Explain It in an Interview

1. Separate the write and read flows

I would separate the design into a write flow and a read flow. The write flow protects correctness. The read flow protects response time.

The Pricing Admin or Internal Tool updates one product with PUT /v1/products/{id}/price. The Product Launch Page or Web Client reads one product with GET /v1/products/{id}/price.

Both requests enter through the API Gateway and Auth layer. This layer authenticates the caller, checks access, and routes the request to the correct API.

2. Validate and store a price update

The gateway authorizes the update and sends it to the Price Update API. The Price Update API passes the request to Validation and Idempotency.

Validation rejects an invalid payload with 400. Idempotency means a repeated request does not create another logical update. An unauthenticated or unauthorized caller receives 401 or 403. A missing product returns 404. A request using an older version returns 409 for a stale-version conflict.

After these checks, the service performs a transactional write to the Primary Price Store. This store is authoritative, which means it owns the official price. It returns the saved version and updatedAt value to the Price Update API. The API then returns 200 OK through the gateway to the admin tool.

3. Publish the update to supporting systems

After the successful write, the Price Update API publishes a price-updated event to the Event Bus and Cache Invalidation component.

The event invalidates or refreshes the Distributed Cache or Edge Cache. It also updates the Read Replica or Read Model asynchronously. These actions are not part of the synchronous admin response path.

The Price Update API also sends audit records and operational logs to Observability and Audit Logs. This helps operators trace who changed a price and investigate failures.

4. Serve the normal low-latency read path

The web client sends GET /v1/products/{id}/price to the API Gateway. The gateway routes it to the Price Read API.

The Price Read API first performs a cache lookup. On a cache hit, the Distributed Cache or Edge Cache returns the price payload. The read response includes freshness metadata such as the version and updatedAt value.

The Price Read API returns 200 OK through the gateway. The gateway then sends the low-latency response to the product page. This avoids reading the Primary Price Store for normal page traffic.

5. Handle a cache miss or stale value

If the cache misses or contains stale data, the Price Read API falls back to the Read Replica or Read Model. The read model returns the latest replicated price.

The Price Read API then warms the distributed cache. Later requests can use the fast cache path again.

The cache and read model are eventually consistent. This means they may briefly lag behind the Primary Price Store. The design accepts this because prices change at most daily. The version and updatedAt value let clients detect the age of the data.

6. Explain freshness and the main trade-off

The cache time-to-live stays below one day. Event-driven invalidation should normally refresh it much sooner. The API can also support ETag and If-None-Match, which let a client ask whether its saved version is still current.

The benefit is very fast reads and lower load on the authoritative store. The downside is more components and a short period of possible stale data. We accept this because freshness is visible and the Primary Price Store remains authoritative.

Practical Complexity & Trade-offs

The design gives writes and reads different paths because they have different needs. A write needs authentication, authorization, validation, idempotency, and a transactional source of truth. A read needs low latency, so it normally uses the distributed cache. The benefit is fast product-page responses and less pressure on the Primary Price Store. The downside is that the cache and read model may briefly hold an older price. Version and updatedAt make that delay visible. Event-driven refresh usually updates the cache quickly, while a cache lifetime below one day provides another freshness limit. Asynchronous replication keeps the update response fast, but it adds operational work. The team must monitor failed events, replication delay, cache refreshes, and audit records. Optional ETag support can reduce repeated data transfer.

Why Interviewers Ask This

Interviewers use this question to test engineering judgment rather than memorization. They want to see clear API boundaries, correct HTTP methods, and separate request and response flows. They also evaluate authentication, authorization, validation, idempotency, caching, versioning, and error handling. A strong candidate explains why the Primary Price Store is authoritative while the cache and read model may briefly lag. The interviewer also checks whether the candidate can explain performance, reliability, freshness, and trade-offs in simple language.

Interviewer may ask next

How would the design change if prices started changing many times per minute?

I would keep the same endpoints and component boundaries, but I would reduce the accepted freshness window. The admin would still use PUT /v1/products/{id}/price, and the product page would still use GET /v1/products/{id}/price. The Primary Price Store would remain authoritative.

The main change would be the event and cache-refresh capacity. Every successful update would still publish a price-updated event. The Event Bus and Cache Invalidation component would need enough throughput to process frequent updates without a growing delay. The Read Replica or Read Model would also need lower replication lag.

I would shorten the cache time-to-live because prices could become old quickly. Version and updatedAt would remain in responses, and stale-version conflicts would still return 409. Authentication, authorization, validation, and idempotency would remain unchanged.

The downside is more event traffic, more cache churn, and higher operating cost. The system would also need closer monitoring because even a small processing delay would affect freshness more quickly.

What happens if the distributed cache is unavailable during a product launch?

The Price Read API would use the Read Replica or Read Model as the fallback shown in the design. The web client still sends GET /v1/products/{id}/price through the API Gateway. The gateway still authenticates the caller and routes the request to the Price Read API.

The read service first attempts the normal cache lookup. When the cache is unavailable, that lookup cannot return a hit. The Price Read API then requests the latest replicated price from the Read Replica or Read Model. It returns the price with its version and updatedAt freshness information through the gateway.

When the distributed cache becomes available again, the Price Read API can warm it using the returned read-model value. Later requests then return to the normal low-latency cache path.

The Primary Price Store remains outside the launch-page read path. This protects the authoritative store from a sudden traffic spike. The downside is higher latency and more load on the read model until the cache recovers.

6. Define the API and state model for a file upload and download system.API DesignMediumMicrosoft

Question Details

Define the API contracts and state transitions for uploading, downloading, and synchronizing files between a local client and a host. Include resource identifiers, status inspection, retries, concurrency, validation, errors, and idempotency.

Short Interview Answer (30-60 seconds)

At a high level, I would separate file metadata from file content. The Desktop or Mobile Client creates an upload session through the File API, uploads chunks to Blob or Object Storage, and then completes the upload. Validation and Auth checks the token, size, checksum, and quota. The Metadata Store keeps the file version and state. Downloads read metadata before returning file bytes. Synchronization uses a cursor to return only new changes. Idempotency-Key supports safe retries, while If-Match with version detects concurrent updates. The trade-off is more state and coordination, but failures become easier to manage.

Detailed Explanation

This system lets a desktop or mobile device safely move files to and from a host. It must support uploads, downloads, progress checks, and file changes from other devices. It must also handle weak networks, repeated requests, invalid files, and two devices editing the same file. The design separates the client, API work, stored file information, file bytes, and the file lifecycle. I would ask the interviewer:

Useful Questions to Ask the Interviewer

What is the largest supported file size?
Must an interrupted upload continue from its last completed part?
Can several devices update the same file?
How long must synchronization changes and deletion records remain available?

Define the API and state model for a file upload and download system. diagram

How to Explain It in an Interview

1. Define the boundaries and identifiers

I would separate the design into four areas. The Local Client contains the Desktop or Mobile Client, Local Cache, and Retry Queue. The API Layer contains the File API, Validation and Auth, and Sync Endpoint. Storage and Data contains the Metadata Store, Blob or Object Storage, and Audit or Event Log. The State Lifecycle explains each valid file state.

The main identifiers are fileId, sessionId, version, ETag, checksum, cursor, and Idempotency-Key. The fileId identifies a file. The sessionId identifies an upload session. The version tracks file changes. The ETag identifies stored content. The checksum verifies content integrity. The cursor marks synchronization progress.

2. Create and complete an upload

The client first sends POST /upload-sessions with name, size, and checksum to the File API. The File API returns 201 with sessionId, fileId, uploadUrl, and version.

The client then sends PUT /uploads/{sessionId} with chunks and an Idempotency-Key. Blob or Object Storage holds the uploaded file data. The response is 200 with an ETag or part-uploaded result.

After every part is uploaded, the client sends POST /files/{fileId}/complete with parts and checksum. The File API asks Validation and Auth to validate the token, size, checksum, and quota. Validation and Auth returns either success or a 4xx error.

The File API then persists fileId, version, and state in the Metadata Store. The store returns stored. The File API also sends an upload.completed event to the Audit or Event Log.

3. Download and inspect a file

The client requests file information with GET /files/{fileId}. The File API looks up metadata in the Metadata Store. The store returns the metadata and storage location. The client receives 200 with downloadUrl, ETag, version, and state.

The client then sends GET /downloads/{fileId}. Blob or Object Storage returns 200 with the file bytes. This separation keeps large file content out of the metadata store.

The client can inspect progress with GET /files/{fileId}/status. The File API returns 200 with state, version, lastModified, and retryAfter. The Local Cache can keep the latest local file information while the client polls for changes.

4. Synchronize changes between devices

The client sends GET /sync?cursor=... to the Sync Endpoint. The Sync Endpoint reads changes from the Metadata Store. The store returns changes and tombstones. A tombstone represents a deleted file entry.

The Sync Endpoint returns 200 with changes and nextCursor. The client saves nextCursor and sends it in the next synchronization request. This avoids downloading the complete change history every time.

5. Handle conflicts, retries, and failures

For an update, the client sends PUT /files/{fileId} with If-Match: version. The version check provides optimistic concurrency. This means the update is accepted only when the client still has the current version.

If another device changed the file first, the response is 409 conflict or 412 precondition failed. The Audit or Event Log records conflict, retry, and error events.

The Retry Queue repeats a temporary failed operation with the same Idempotency-Key. The File API may return 429 or 503 with retryAfter. Reusing the key reduces the risk of performing the same operation twice.

6. Explain the file lifecycle

The normal upload path is NEW, SESSION_CREATED, UPLOADING, UPLOADED, VALIDATING, and READY. A failure during uploading or validation moves the file to FAILED. It then moves to RETRY_PENDING before returning to UPLOADING.

A READY file can move to DOWNLOADING and then return to READY. Synchronization moves it through SYNC_PENDING and SYNCED before it returns to READY. A version conflict moves it through CONFLICT and RESOLVED. A file may also move from READY to DELETED.

The state model makes progress and failure handling visible. It also prevents clients from treating an incomplete file as ready.

Practical Complexity & Trade-offs

The benefit is that each component has one clear job. Blob or Object Storage handles large file bytes. The Metadata Store keeps identifiers, versions, locations, and states. The File API coordinates requests, while Validation and Auth checks the token, size, checksum, and quota. The downside is that metadata and file content must remain consistent across separate systems. Upload sessions and states make recovery easier, but they add more records and transitions. Idempotency-Key makes retries safer, but the service must remember previously processed keys. If-Match with version prevents silent overwrites, but clients must handle 409 and 412 responses. Cursor-based synchronization reduces repeated work, but cursors and tombstones must be managed carefully. We accept this extra complexity because file transfers often fail and may involve several devices.

Why Interviewers Ask This

Interviewers use this question to test engineering judgment rather than endpoint memorization. They want to see clear resource identifiers, correct request and response directions, sensible ownership of metadata and file bytes, and a useful state model. They also evaluate validation, status inspection, synchronization, retry safety, concurrent updates, HTTP error handling, and audit logging. A strong candidate should explain why each choice exists and describe the design trade-offs without promising perfect reliability or exactly-once behavior.

Interviewer may ask next

How would this design recover when a large upload loses its network connection?

I would continue using the same upload session and retry only the parts that were not accepted. The affected flow is PUT /uploads/{sessionId} with file chunks and an Idempotency-Key. The client keeps completed-part information in its Local Cache. Blob or Object Storage returns an ETag or part-uploaded result for each accepted part.

When the connection returns, the Retry Queue repeats the failed operation with the same Idempotency-Key. Reusing the key reduces duplicate processing. If the service is busy or temporarily unavailable, the File API can return 429 or 503 with retryAfter. The client waits before trying again.

After all parts are available, the client still sends POST /files/{fileId}/complete with parts and checksum. Validation and Auth verifies the token, size, checksum, and quota before the file can reach READY. The main downside is extra client state. The client must remember uploaded parts and keep them matched to the correct sessionId.

How would the system prevent two devices from silently overwriting the same file?

I would keep the existing version and If-Match design. Each device reads the current version through GET /files/{fileId} or GET /files/{fileId}/status. When a device sends PUT /files/{fileId}, it includes If-Match: version.

The File API compares that value with the current version in the Metadata Store. The first valid update can advance the version. A later update carrying an older version receives 409 conflict or 412 precondition failed. The file then follows the CONFLICT and RESOLVED states before returning to READY.

The Audit or Event Log records the conflict. The Sync Endpoint later includes the new change when another device calls GET /sync?cursor=.... This keeps the existing upload, download, and synchronization design unchanged.

The benefit is that one device cannot silently replace another device's work. The downside is that the client must show a conflict or provide a safe way to resolve it.

7. Define the APIs for a scalable multi-channel OTP system.API DesignHardMicrosoft

Question Details

Define APIs for generating and validating OTPs delivered through channels such as SMS, WhatsApp, and email, while supporting multiple clients for one user and ensuring each OTP is unique per user request. Cover contracts, expiration, retries, idempotency, rate limits, and errors.

Short Interview Answer (30-60 seconds)

At a high level, I would expose two versioned APIs: POST /v1/otp/generate and POST /v1/otp/validate. Clients call them through HTTPS with a JWT. Generate requests also include an Idempotency-Key. The PHP OTP API checks rate limits, duplicate requests, channel rules, and expiration. It stores only the OTP hash, then sends the code through SMS, WhatsApp, or email. Validation checks the stored hash, expiry, and remaining attempts. Retry and channel fallback improve delivery, but they add operational complexity and must not create extra OTPs.

Detailed Explanation

This system lets a user receive a short one-time code and prove they entered it correctly. The same user may use a web app, mobile app, or partner app. The code may arrive through SMS, WhatsApp, or email. The main challenge is preventing duplicate codes, limiting abuse, handling expired codes, and recovering from provider failures. I would explain the design in the same order as the diagram: accept the client request, apply checks, store safe OTP data, deliver through an adapter, validate the submitted code, and record operational events.

Useful Questions to Ask the Interviewer

How long should each OTP remain valid?
How many failed validation attempts are allowed?
Should fallback to another channel happen automatically?
Which limits apply per user, client, destination, or channel?

Define the APIs for a scalable multi-channel OTP system. diagram

How to Explain It in an Interview

1. Define the API boundary

I would expose two endpoints through the API Gateway and PHP OTP API. POST /v1/otp/generate creates and sends an OTP. POST /v1/otp/validate checks a submitted OTP.

Both requests use HTTPS and a JWT. The generate request also carries an Idempotency-Key. Its body contains user_id, client_id, channel, destination, and purpose. A successful generate call returns 201 with otp_request_id, expires_at, and retry_after_sec.

The validate body contains otp_request_id, user_id, client_id, and otp_code. Its visible responses are 200 verified, 400 invalid, 410 expired, and 429 rate_limited.

2. Check the generate request

The generate request first reaches the PHP OTP API. The Rate Limiter checks whether the request is allowed. If the limit is exceeded, the service returns 429 rate_limited.

The Idempotency / Request Deduper then checks the Idempotency-Key. Idempotency means that repeating the same client action does not create another OTP. If the request was already processed, the API returns the existing result or reports 409 duplicate_request when the request conflicts.

The OTP Policy & Validator checks the client, selected channel, and OTP lifetime. An invalid request returns 400 invalid_request. Missing or invalid authentication returns 401 unauthorized. An unsupported channel returns 422 channel_not_supported.

3. Create and store safe OTP state

After the checks pass, the service creates a unique request_id and OTP hash. It stores otp_hash, request_id, user_id, client_id, channel, expires_at, status, and attempts_left in the OTP Store.

The plain OTP is not stored. The request_id connects later validation to the correct record. Including both user_id and client_id allows one user to use several clients without mixing their OTP requests.

4. Deliver through the selected channel

The Delivery Orchestrator routes the OTP to the correct channel adapter. The SMS Adapter calls the SMS Provider. The WhatsApp Adapter calls the WhatsApp Business API. The Email Adapter calls the Email Provider.

A provider returns an accepted result or message identifier through its adapter. The orchestrator tracks the delivery status. If the provider fails, the Failure / Retry Queue or Fallback Logic applies retries with backoff. It may use an alternate channel when that behavior is configured. These retries continue to represent the same OTP request.

A provider failure may produce 500 provider_error when the request cannot be completed successfully.

5. Validate the submitted OTP

For POST /v1/otp/validate, the service first applies the validation attempt limit. It then loads the OTP record using otp_request_id, user_id, and client_id.

The OTP Policy & Validator compares the submitted code with the stored hash. It also checks expires_at, status, and attempts_left. A correct code returns 200 verified and marks the record as used. A wrong code returns 400 invalid and reduces attempts_left. An expired record returns 410 expired. Too many requests or attempts return 429 rate_limited.

6. Record events and explain the trade-off

Audit Logs / Metrics receives events, errors, latency, request metadata, and delivery metrics. This is a supporting path. It does not produce the business response.

The main benefit is clear ownership. The PHP OTP API owns the contracts. The policy component owns OTP rules. The store owns OTP state. The orchestrator owns delivery routing. The downside is more components and more failure cases. We accept that complexity because it supports several channels, avoids duplicate OTP creation, protects stored codes, and gives predictable error behavior.

Practical Complexity & Trade-offs

The benefit of this design is that each responsibility is clear. The API handles contracts and client responses. The policy component checks OTP rules. The store keeps OTP state. The orchestrator handles delivery. Idempotency stops repeated generate calls from creating extra OTPs. Rate limiting reduces abuse, but limits that are too strict may block real users. Storing only the OTP hash is safer, but the original code cannot be recovered from storage. Channel adapters make providers easier to replace, but every adapter needs maintenance. Retry with backoff improves delivery, but repeated sends must reuse the same OTP request. Fallback can improve success rates, but it may increase cost and surprise users. We accept these trade-offs for safer and more reliable delivery.

Why Interviewers Ask This

Interviewers use this question to test whether you can turn product needs into clear API contracts. They look for correct request and response flows, safe OTP storage, expiration, idempotency, rate limiting, and useful errors. They also check whether you separate API processing, provider delivery, retry behavior, and audit logging. A strong answer shows good judgment about multiple clients, channel fallback, security ownership, scalability, and the cost of adding more operational components.

Interviewer may ask next

How would this design handle a sudden ten-times increase in OTP traffic?

I would keep POST /v1/otp/generate and POST /v1/otp/validate unchanged. The main change would be scaling the existing PHP OTP API, OTP Store, Delivery Orchestrator, and channel adapters. Additional PHP OTP API instances can process requests because the important request state remains in the OTP Store and idempotency records.

The Rate Limiter must apply consistent limits across all API instances. The OTP Store must support more writes during generation and more lookups during validation. The Delivery Orchestrator and each adapter can scale separately because SMS, WhatsApp, and email providers may have different throughput limits.

When providers slow down, the existing Failure / Retry Queue should hold failed delivery work and apply backoff. This prevents provider problems from causing uncontrolled retries. Idempotency still ensures that a repeated generate action does not create another OTP. The downside is higher infrastructure cost and possible delivery delay during a large traffic spike.

What should happen when the selected messaging provider is unavailable?

The Delivery Orchestrator should send the failed attempt to the existing Failure / Retry Queue or Fallback Logic. The retry policy should wait between attempts by using backoff. If fallback is configured, the orchestrator may route the same OTP request through another supported channel.

The system must keep the same otp_request_id and stored OTP hash. It should not generate a second OTP for the same request, because that could leave several valid codes active. The adapter should record whether the provider accepted the message and any message identifier that was returned. Provider failures and retry activity should also be sent to Audit Logs / Metrics.

Expiration, status, and rate-limit rules remain unchanged during retries. If delivery cannot be completed, the API may report 500 provider_error. The main downside of fallback is extra cost and possible user surprise, so the allowed fallback channels should be controlled by policy.

8. Design a multi-region URL shortener.System DesignHardMicrosoft

Question Details

Design a URL-shortening service with emphasis on multi-region deployment and identifier generation. Discuss request flow, storage, uniqueness, Base62-style encoding, replication, failover, and consistency tradeoffs.

Short Interview Answer (30-60 seconds)

At a high level, this service turns long URLs into short links and redirects users quickly. The main challenge is keeping codes unique while two regions create links independently. I would explain three paths: link creation, redirects, and background analytics. Global DNS sends requests to the nearest healthy region. PHP services generate region-scoped IDs, encode them with Base62, and save mappings in the local PostgreSQL primary. Redis speeds up redirects. The trade-off is that asynchronous replication can leave the other region slightly behind.

Detailed Explanation

The system must turn a long URL into a short code. When someone opens that code, the system must quickly redirect them to the original destination. The difficult part is running in two regions while keeping generated codes unique. Redirect traffic must also remain fast when one region has a problem. The diagram separates the solution into a create path, a redirect path, and background analytics. Each region handles requests locally. New mappings are copied to the other region later, so remote data may briefly be older.

Useful Questions to Ask the Interviewer

Should short links ever expire?
Do we need only generated codes, or also custom aliases?
Should redirects use HTTP 301 or HTTP 302?
How much cross-region delay is acceptable?
Should both regions accept new links at the same time?

Design a multi-region URL shortener. diagram

How to Explain It in an Interview

1. Start with global routing

I would first route every request through Global DNS and the Traffic Manager. Geo Routing sends the client to the nearest healthy region. Active Health Checks watch Region A and Region B. If one region becomes unhealthy, Automatic Failover sends traffic to the other region.

Each region has a Regional Load Balancer. It sends POST /shorten to the Shortener Service. It sends GET /{code} to the Redirect Service. Both services run inside the PHP 8.4 or 8.5 Runtime using Nginx and PHP-FPM.

2. Explain the create path

For the create path, the Shortener Service validates the URL and applies rate limits. The ID Generator then creates a numeric ID from that region's own ID space. Region A and Region B use separate spaces, so they can create links independently without generating the same ID.

The Base62 Encoder changes the numeric ID into a compact, URL-friendly code. Base62 only makes the value shorter. The region-scoped ID provides uniqueness. The service writes the URL mapping to the local PostgreSQL Primary first. After the database write succeeds, it updates the local Redis Cache and returns 201 Created with the short URL.

3. Explain the redirect path

For the redirect path, the Redirect Service checks the local Redis Cache first. This is the fast path for popular links. On a cache hit, it returns a 301 or 302 redirect to the long URL.

If the cache misses, the service performs a DB Lookup against the local PostgreSQL Primary. It reads the mapping, fills Redis, and then returns the redirect. PostgreSQL is the main source of the URL mapping. Redis only makes repeated lookups faster.

4. Explain background analytics

The redirect response should not wait for analytics. Click information is sent to the local RabbitMQ Queue as background work. PHP CLI Analytics Workers consume the queued events and save analytics results.

The diagram also shows asynchronous analytics queue events moving between regions. This gives the analytics path another way to continue processing during regional problems. Logs, Metrics, and Traces go to Observability. These signals help the team find slow requests, queue problems, and unhealthy regions.

5. Explain replication and trade-offs

Each region writes mappings created there to its local PostgreSQL Primary. Logical Asynchronous DB Replication then copies those mappings between Region A and Region B. Asynchronous means the local write finishes before the other region receives the data.

This keeps local writes fast and helps the healthy region serve traffic after failover. The downside is a small delay. A newly created link may not exist in the other region immediately. Remote reads or replicated data may therefore be slightly stale during replication lag. The design accepts this because local redirects stay fast, region-scoped IDs prevent collisions, and the Traffic Manager can route around an unhealthy region.

Engineering Considerations / Design Trade-offs

The benefit is that both regions can create links and serve nearby users. Redis makes popular redirects fast. Region-scoped IDs stop the two regions from creating the same code. The downside is that PostgreSQL replication works in the background. A new mapping may reach the other region a little later. Automatic failover keeps traffic moving, but the healthy region may briefly have older data. RabbitMQ and PHP CLI workers keep analytics away from the redirect response, but they add more parts to operate. We accept these costs because fast local redirects and regional availability are the main goals.

Why Interviewers Ask This

Interviewers use this question to test how you divide a large system into clear flows. They want to see whether you understand unique ID generation, Base62 encoding, database-first writes, cache-aside reads, background analytics, replication, and regional failover. They also want honest trade-offs. A strong answer explains why each part exists without claiming instant replication, perfect availability, or uniqueness from Base62 alone.

Interviewer may ask next

How would you change the design if a newly created short link must work immediately in both regions?

I would keep the same basic design, but I would change when the Shortener Service returns success. Today, the local PostgreSQL write completes first. Logical Asynchronous DB Replication copies the mapping to the other region later.

For immediate cross-region reads, the create path would wait until the other region confirms that it has stored the mapping. Only then would the service update the local Redis Cache and return 201 Created. The ID Generator would still use region-scoped ID spaces, so the uniqueness rule would remain unchanged.

This makes the new link available from either region before the client receives success. The downside is slower link creation. A network problem between Region A and Region B could also block new creates, even when the local region is healthy. Redirects would remain fast, but the create path would become less available.

What happens if Redis fails in one region?

The Redirect Service can keep working by using the existing DB Lookup path. Redis is a speed layer, not the source of the URL mapping.

A GET /{code} request still enters through Global DNS, the Regional Load Balancer, and the Redirect Service. The service tries the local Redis Cache. If Redis is unavailable, it reads the mapping from the local PostgreSQL Primary and returns the 301 or 302 redirect. Cache-fill attempts should stop or fail quickly until Redis recovers.

Correctness remains safe because PostgreSQL contains the saved mapping. Observability should show the Redis failure through Logs, Metrics, and Traces. This helps the team see higher database traffic and slower redirects.

The downside is extra load on PostgreSQL. Popular links that normally stay in Redis will require database lookups, so response time may rise until the cache becomes healthy again.

9. Design an alert-monitoring system for machine sensors.System DesignHardMicrosoft

Question Details

Design a system that monitors multiple machines with sensor types such as temperature and pressure. Each sensor has lower and upper thresholds; out-of-range values create alerts that users can view and transition to states such as acknowledged, resolved, or ignored.

Short Interview Answer (30-60 seconds)

At a high level, this system accepts machine readings and creates alerts when values leave their safe range. The main challenge is keeping sensor ingestion fast while storing correct alert states and user actions. I would explain three flows: sensor ingestion and evaluation, alert viewing and state changes, and background notification delivery. PHP-FPM workers handle web requests, while PHP CLI workers process queued jobs. Redis speeds up common lookups, but the relational database remains the source of truth. The trade-off is more operational complexity.

Detailed Explanation

The system watches readings from machines, such as temperature and pressure values. Each sensor has a lower and upper safe limit. When a value leaves that range, the system must create or update an alert. Operators must view alerts and change them to acknowledged, resolved, or ignored. The hard part is accepting readings quickly without losing correct alert decisions or user actions. The diagram separates the solution into sensor ingestion, operator access, and background notification work.

Useful Questions to Ask the Interviewer

How often does each sensor send a reading?
Can a machine send the same reading more than once?
How quickly must a new alert become visible?
Which users may view or update each machine's alerts?
Which notification channels are required?

Design an alert-monitoring system for machine sensors. diagram

How to Explain It in an Interview

1. Explain the clients and entry checks

I would start by separating machine requests from operator requests. Machines and sensors send readings as REST and JSON requests. Operators use the User Web UI / Dashboard to view alerts and take actions.

Both paths enter through the API / Edge layer. It applies authentication, authorization, input validation, and rate limiting. Machine API Validation checks the machine credential and identity. User Auth Validation checks the user's session or JWT token. Role-based access controls which alert actions a user may perform.

2. Explain the sensor ingestion flow

For the ingestion path, the validated reading enters the Sensor Ingestion API. It runs on stateless PHP-FPM workers using PHP 8.4 or PHP 8.5. Stateless means requests do not share mutable request data between workers.

The API validates the reading payload and performs basic checks. It also uses the reading identifier to avoid processing a repeated reading twice. It then sends the validated reading to the Alert Evaluation Service.

The evaluation service looks up the sensor's lower and upper thresholds. Redis Cache serves the common threshold lookup. If the cache misses, the service falls back to the Relational Database.

The service compares the reading with the thresholds. It avoids duplicate active alerts for the same problem. It then creates or updates the active alert and stores the reading and decision in the database. The ingestion request can then return its response without waiting for notification delivery.

3. Explain alert viewing and state changes

For the operator path, the dashboard sends view or action requests through the API / Edge layer. The Alert API runs on PHP-FPM workers and uses role-based access.

For alert lists and details, it reads the latest alert and status summaries from Redis Cache. A cache hit provides a fast result. If Redis misses, the Alert API reads the required alert data from the Relational Database. It returns the alert details as JSON.

When an operator acknowledges, resolves, or ignores an alert, the Alert API writes the new state to the database. It also records the user action in the audit history. The database remains the source of truth for readings, alerts, history, and user actions.

4. Explain background notifications

Out-of-range alerts and state changes can create deferred events in the Message Queue. This keeps notification work away from the main request path.

PHP CLI Queue Workers consume jobs from the queue. These are separate from PHP-FPM request workers. They prepare notification work and send it to the Notification Adapter.

The adapter delivers email, SMS, or webhook messages through external notification channels. A transient failure is retried. If all retries are exhausted, the failed job moves to Dead-Letter / Retry Holding for manual inspection and replay.

5. Explain scale, safety, and trade-offs

Stateless PHP-FPM workers can scale horizontally by adding more workers behind the entry layer. Redis reduces repeated threshold and alert-summary lookups. The queue smooths notification spikes during high alert volumes.

Rate limits protect both machine and user endpoints. Role-based access protects alert actions. The audit history records each important state change.

The downside is more moving parts. Redis misses increase database work, and queue failures require retry handling. The relational database must remain the final record when cached data and background processing disagree.

Engineering Considerations / Design Trade-offs

The benefit is that the main request path stays focused. Stateless PHP-FPM workers can scale by adding more workers. Redis makes threshold checks and alert-summary reads faster. The Message Queue prevents notification spikes from slowing the APIs. The Relational Database keeps the official record of readings, alerts, history, and user actions. The downside is more moving parts. Redis may miss, so the services need a database fallback. Queue jobs may fail, so workers need retries and Dead-Letter / Retry Holding. Duplicate readings and active alerts also need careful checks. We accept this complexity because requests stay responsive and important data remains safe.

Why Interviewers Ask This

Interviewers use this question to test how a candidate breaks one system into clear flows. They want to see correct choices for request workers, background workers, caching, and the main database. They also check how the candidate handles repeated readings, alert state changes, access control, retries, and failed jobs. The strongest answers explain why each choice exists and discuss the downside honestly.

Interviewer may ask next

How would the design handle a sudden burst from thousands of sensors?

I would keep the same architecture and scale the stateless request path first. More PHP-FPM workers could run behind the API / Edge layer. Per-machine rate limits would stop one machine from using too much capacity.

The Sensor Ingestion API would still validate every payload. It would also use the reading identifier to avoid processing repeated readings. The Alert Evaluation Service would continue reading common thresholds from Redis Cache. This reduces repeated database work during the burst.

The Relational Database would still store each accepted reading and alert decision. Notification events would enter the Message Queue instead of being delivered inside the API request. More PHP CLI Queue Workers could be added when the queue grows.

This keeps alert decisions correct because the database remains the source of truth. The main downside is higher infrastructure cost. Notifications may also arrive later while queued work is being processed.

What should happen when Redis Cache is unavailable?

The system should continue by using the Relational Database as the fallback. The Alert Evaluation Service would read sensor thresholds from the database when Redis cannot answer. The Alert API would also read alert lists and details from the database when cached summaries are unavailable.

No official alert data is lost because Redis is only a speed layer. Readings, active alerts, alert history, and user actions remain in the Relational Database. Sensor ingestion and operator requests may become slower because more queries reach the database.

The API / Edge rate limits can help control the extra load. When Redis becomes healthy again, normal cache lookups can resume. The design should never treat the cached copy as the only copy of important data.

The main downside is reduced performance during the outage. The database may handle less traffic until Redis is available again.

10. Design a distributed key-value store like Redis.System DesignHardMicrosoft

Question Details

Design a distributed key-value store and explain data partitioning, replication, failover, consistency and availability tradeoffs, request routing, persistence, and recovery.

Short Interview Answer (30-60 seconds)

At a high level, the goal is to store key-value data safely and return reads very quickly. The main challenge is spreading keys across many shards while keeping routing, replication, and failover correct. I would explain the write path, the read path, and the recovery path. Stateless PHP-FPM workers process requests, and the Request Router sends each key to its shard. Primaries handle writes, replicas can serve reads, and the main trade-off is faster availability versus stronger consistency.

Detailed Explanation

The system must save a value under a key and return it when a client asks for that key. It must stay fast as the amount of data grows. It should also continue working when a storage node fails. The difficult part is deciding where each key belongs, keeping backup copies updated, and routing requests after a failure. The diagram organizes the solution into request entry, PHP processing, shard routing, replicated storage, failover, recovery, rebalancing, and monitoring.

Useful Questions to Ask the Interviewer

Must every read return the newest confirmed value?
Can reads use replicas that may be slightly behind?
How much write loss is acceptable during failover?
How durable must the stored values be?
How quickly should a failed shard recover?

Design a distributed key-value store like Redis. diagram

How to Explain It in an Interview

1. Explain how a key reaches one shard

I would start by saying that every key belongs to one shard. A shard is one section of the complete data set.

The Request Router uses the Partition Map to find the correct shard. It turns the key into a hash or slot and looks up the current owner. This spreads keys across Shard 1, Shard 2, and Shard N.

When the cluster changes, the PHP CLI Worker handles rebalance and reshard work. It moves slots or keys without placing that work inside normal PHP-FPM requests.

2. Explain the write path

For a write, the client sends a SET request to the Edge Layer. The API Gateway and Load Balancer handle the connection and TLS termination. Authentication, ACL checks, validation, and rate limits run before application work begins.

The request then reaches a stateless PHP-FPM worker in the PHP 8.4 or 8.5 Service Layer. Stateless means request-local mutable data is not shared automatically across workers.

The worker sends the key to the Request Router. The router checks the Partition Map and forwards the request to the Primary of the correct shard. The Primary stores the value in memory, records changes in the Append-Only Log, and creates periodic snapshots. The ACK returns through the PHP and Edge layers to the client.

3. Explain the read path

For a read, the client sends a GET request through the same Edge and PHP layers. The Request Router again uses the key-to-slot lookup to find the correct shard.

The read may go to the Primary or a Replica. A Replica is a backup copy that receives updates from the Primary. Replica reads can reduce load and latency, but the returned value may be slightly old.

The selected node returns either the value or a miss. That result travels back through the Request Router, PHP-FPM worker, and Edge Layer.

4. Explain replication, failover, and recovery

Each Primary sends updates to its Replicas using asynchronous replication. This means the Primary can reply before every Replica confirms the update.

The Coordination and Failover Service tracks membership and performs health checks. It also handles failure detection, leader election, Partition Map management, and rebalance coordination. If a Primary fails, the service promotes a Replica and refreshes the Partition Map so future requests reach the new Primary.

When a shard node restarts, it loads its latest snapshot and replays the Append-Only Log. This restores changes written after the snapshot.

5. Explain monitoring and the main trade-off

Observability collects metrics, logs, traces, and alerts from the Edge Layer, PHP workers, router, shards, and failover service. This helps operators detect slow requests, unhealthy nodes, failed recovery, and delayed replication.

The main trade-off is consistency versus availability. Replica reads and asynchronous replication keep the service fast and available. However, a Replica may return old data, and the newest write may be lost during a sudden failover. Primary reads or waiting for Replica acknowledgments gives stronger consistency, but increases latency and can reduce availability.

Engineering Considerations / Design Trade-offs

The benefit is that partitioning lets the store grow across many shards. Replicas can also keep reads available when a node fails. The downside is that a Replica may be slightly behind its Primary. A Replica read can therefore return an older value. Asynchronous replication keeps writes fast, but the newest write may be lost during a sudden failure. Reading only from the Primary gives fresher data, but adds more load to that node. Waiting for Replica acknowledgments makes writes safer, but increases response time. Rebalancing also moves keys between shards, which adds background work and operational risk.

Why Interviewers Ask This

Interviewers ask this question to test how a candidate breaks a large storage problem into clear flows. They want to hear how keys are partitioned, how requests find the correct shard, and how replicas help during failures. They also test whether the candidate understands persistence, recovery, stateless PHP-FPM workers, routing updates, and the trade-off between fast availability and fresh data.

Interviewer may ask next

How would the design change if every read must return the newest confirmed value?

I would keep the same components, but I would change the read and write rules. The Request Router would send all reads to the Primary of the correct shard. It would not use Replicas for normal reads because a Replica may be slightly behind.

For stronger write safety, the Primary could wait for one or more Replica acknowledgments before returning the ACK. An acknowledgment means a Replica confirms that it received the update. The Primary should still record the change in its Append-Only Log before confirming success.

The Coordination and Failover Service would promote only a Replica that has the latest confirmed updates. It would then refresh the Partition Map so new requests reach the new Primary.

The main downside is higher latency. Reads place more load on Primaries, and writes wait longer for Replicas. During a network problem, the system may reject some requests instead of returning data that could be old.

How would you reduce the risk of losing the newest writes during failover?

I would keep the same shard, persistence, and failover design. I would mainly change when the Primary returns the write ACK.

The Primary would first record the change in its Append-Only Log. It would then send the update to its Replicas and wait for at least one Replica acknowledgment. This makes it more likely that another node has the newest confirmed value before the client receives success.

The Coordination and Failover Service should track which Replica has the latest confirmed updates. If the Primary fails, it should promote that Replica and refresh the Partition Map. A restarted node can still load its snapshot and replay its Append-Only Log.

The downside is slower writes. A slow or unreachable Replica can delay the response. The system may also accept fewer writes during a network problem because it waits for more safety before confirming success.

21 Microsoft Php Developer Interview Questions & Answers

Questions with Detailed ExplanationsWith Detailed Explanations

1. Return the top K most frequent error codes from log lines.CodingEasyMicrosoft

2. Reverse the nodes of a linked list in groups of K.CodingHardMicrosoft

3. Design a search API for finding nearby service providers.API DesignHardMicrosoft

4. Design a secure API for an enterprise AI copilot.API DesignHardMicrosoft

5. Design a low-latency product-price update API.API DesignHardMicrosoft

6. Define the API and state model for a file upload and download system.API DesignMediumMicrosoft

7. Define the APIs for a scalable multi-channel OTP system.API DesignHardMicrosoft

8. Design a multi-region URL shortener.System DesignHardMicrosoft

9. Design an alert-monitoring system for machine sensors.System DesignHardMicrosoft

10. Design a distributed key-value store like Redis.System DesignHardMicrosoft

Php Developer Resume Examples