SF Architect Interview Scenario at Amazon Seattle

The interviewer presented a scenario where

1. A Restaurant Order Service (let’s call it Service 1) receives new orders (like “Burger, Coke, Fries”) from a customer and sends an acknowledgment to Salesforce. It looks something like:

{
  "OrderID": "someText"
}

indicating, “Yes, we got your order.”

2. Another Service (Service 2) in the restaurant then sends updates when items are ready. However, these updates might come in partial form—if the burger is ready but the fries aren’t, you’ll get an update just for the burger. So a payload could be:

{
  "OrderID": 123,
  "status": "Burger Ready"
}

with no mention of the fries or coke. That means we’re dealing with incremental statuses.

3. Salesforce has an Order__c object to track the overall order. Potentially, you might also have OrderItem__c records for each item. The system must show an end user the current status of each item (e.g., “Burger: Ready,” “Coke: Pending,” “Fries: In Progress”).

The Core Challenge

The big twist is that you cannot make the external service wait for a full, final response before acknowledging you got the message. Cooking times can vary, and the entire order might take quite a while to complete. Meanwhile, partial updates come in for individual items. So how do you architect a Salesforce inbound web service (or integration approach) that:

• Accepts small status updates for items.

• Responds quickly to confirm receipt.

• Updates Order__c (and possibly item records) asynchronously.

• Handles errors (e.g., out-of-stock or canceled items) gracefully.

• Scales for a busy restaurant with potentially thousands of orders every day.

“You can’t wait on the entire meal—you still need to serve the burger while the fries are cooking.”