Event-driven architecture: handling eventual consistency in the UI

our backend team has fully embraced an event-driven architecture, which has been great for decoupling services and scalability. however, our frontend team is really struggling with the implications of eventual consistency, especially for user-facing actions. for example, a user creates an order, the event is published, and the backend processes it asynchronously. but if the user immediately navigates to their order history page, the order might not show up for a few seconds because the read model hasn't been updated yet. this creates a really confusing and frustrating user experience. we've tried things like showing a 'pending' state or using polling, but it feels clunky. how do others bridge this gap between an asynchronous, event-driven backend and the user's expectation of immediate feedback and synchronous UI updates? are there patterns or client-side techniques that can help make eventual consistency less jarring for the end-user?