So the usual answer is that instead of using an event delivery system, like Kafka, the "book of record" is a database (could be relational, could be a document store, could be an "event" store).
To answer questions like "what color is entity 12345?", you would load the sequence of events for entity 12345, then compute the color from the history.
Depending on what color is, this might mean paging from the most recent event backwards until you find the most recent event that sets the color, or "replaying" all of the events from the beginning of time to recreate a local copy of the current state of the entity, and then asking your local copy of the entity what color it is.
In other words, for queries, the implementation of the query can have a number of different forms, depending on how events are stored and how they are retrieved from the permanent storage.
It might take a lot of time to check all the events and find what is relevant for a given orderId
Yup, it might. Usual design is to arrange that (copies of) all of the events for a given entity are stored in the same history. In other words, instead of having a single history for an entire topic, we normally will have individual histories for each entity in the topic.
(Reading up on "domain driven design" and the "aggregate" life cycle pattern might help here -- typically each aggregate has a history, where an aggregate is a cluster of closely related entities).
In cases where query latency is a significant concern: we can cache copies of event state, and use those to answer questions. So you get faster, correct answers that reflect the state of the entity at some point in the recent past.
For more on these ideas, see CQRS (command requiry responsibility segregation).
For making updates to the entity state, you need to be a little bit careful with caches, because lost edits are a bummer. We want to arrange our history store so that it has "first writer wins" semantics - either we arrange to lock the history against concurrent modification, or we use a conditional write mechanism to ensure that the location where events are written into the history exactly matches where it was when we started the calculation.