I have an actor which receives a message to perform an operation like sending an alert and this is the actor purpose. To send an alerts. Should I open now a future and wrap the sending of an alert in another async mechanism? or is my actor receive - send alert already the async process I was waiting for?
It really depends on what sending that alert entails. More specifically, does sending that alert entail blocking code. You want to avoid blocking in the default dispatcher for your actor system. If sending the alert entails a blocking operation (like say a synchronous I/O operation), then you can consider a couple of different approaches:
1) Give this actor its own dispatcher so its blocking won't affect the main dispatcher for your actor system. This technique is referred to as "bulk heading" (I prefer "fire-walling") as you are sealing off your slow/blocking (and potentially dangerous code) from the rest of your application. If you have a single actor that sends these alerts, you might want to consider a Pinned Dispatcher which would result in this actor having its own thread for its execution.
2) Wrap the potentially dangerous alert sending code in a Future. This moves the blocking code out of your main dispatcher and into another ExecutionContext (provided you provide a different one for these types of things and don't just use the dispatcher of the actor itself), which should be safer. I don't love this approach as it can lead to closing over mutable state and potentially leading to race conditions (which actors try to avoid in the first place), but if done safely, it can be effective.
I would honestly stick with approach 1 as it better fits the Akka idiom, but that's just my opinion. Either approach can work for you as I'm sure there are a couple of other ones as well.
If sending the alert is non-risky and/or non-blocking, then there is no need IMO to use a Future.