You’re mixing up several terms and ideas, which are important to keep separate. Once you’ve separated those in your head, all should become clear.
Event Sourcing and Event Driven Architecture are two different ideas. Event Sourcing means you keep all changes to an entity in an Event Store and to get the current state of that entity you add up all the events. This concept relates to storage of state, not processing of requests. An Event Driven Architecture is what I think you’re referring to in this question. The need to keep these ideas separate will become clear in a moment.
In an Event Driven Architecture there are two ideas you need to keep separate. There’s the request coming in from a UI or external system to make some change to the data; this is a message or request. The message handler (usually called a command in CQRS) processes the request and either rejects it as invalid or makes appropriate changes to the entities in the system. The changes to those entities are then store as Events in the Event Store. The events in the Event Store should only contain the data that changed, not all the properties of the entity. If more than one entity is changed by the command, more than one event will be written to the event store.
The system can have listeners (or subscribers) to the event store and other business logic can be launched in response to a change in an entity. These changes are run async in an eventually consistent manner.
With all this in mind, we can talk about how an Event Driven Architecture handles both synchronous and async events. Keep in mind that EDA is designed for asynchronous processing and eventual consistency so making it synchronous is a bit of extra work.
Using your 4 steps above we get this
Step 1: No changes to the logic of your description. The gateway receives the request (not an event) and waits.
Step 2: Some developers like to store the incoming requests for pattern analysis and such, but it is not necessary to successfully process the request.
In an eventually consistent architecture the business logic would do some basic validation of the incoming request and if it looks good send back a confirmation that the operation was successful. The request would be put on a queue and handled when convenient. If errors are encountered, the user is notified later.
But since your system is synchronous, the API (what you called the 'API Gateway') would directly call the service responsible for handling the business logic – the command.
Step 3: The request is handled by the command, validating the request and making any necessary changes to entities. Events are created for all entity changes (one event per entity).
Step 4: The command returns a success or failure value synchronously to the API, which returns it to the caller. Note that this should be an async/await call, not a blocking call from the API. To the API and the user it still looks like a synchronous process.