Question 3
A startup is building a food delivery app. The customer-facing screen shows live order status updates: "Order Placed → Preparing → Out for Delivery → Delivered".
Each stage is triggered by the restaurant or the delivery rider updating the status on their end. The customer's screen should reflect these changes in real time without refreshing the page.
Two developers debate about the right technology: Developer A says: "Let's use Server-Sent Events. It's the right fit here." Developer B says: "No, we must use WebSockets. SSE won't work."
Who is correct, and why?
Developer B is correct. SSE cannot transmit JSON data, so structured order status objects cannot be pushed to the browser.
Developer B is correct. SSE connections do not reconnect automatically when the network is briefly interrupted, making it unreliable for a live tracker.
Developer A is correct. The tracker only requires the server to push status updates to the customer, without the customer sending data back through the same connection. SSE is purpose-built for exactly this one-way server-to-client push scenario.
Developer A is correct, but only if WebSockets are set up as a mandatory fallback, since SSE requires HTTP/2 to function.