> For the complete documentation index, see [llms.txt](https://tochemey.gitbook.io/goakt/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://tochemey.gitbook.io/goakt/features/actor/messaging.md).

# Messaging

## Overview

Communication between actors is achieved exclusively through message passing. In GoAkt *Google Protocol Buffers* are used to define messages. The choice of protobuf is due to easy serialisation over wire and strong schema definition. As stated previously the following messaging patterns are supported:

* **`Tell/RemoteTell`** - send a message to an actor and forget it. **`Tell`** is used for local messaging.
* **`Ask/RemoteAsk`** - send a message to an actor and expect a reply within a time period. **`Ask`** is used for local messaging.
* **`SendAsync`** - behave the same way as **`Tell`**. This call is location transparent which means that the system will locate the given actor whether locally or remotely to send the message. This is possible when cluster mode is enabled.
* **`SendSync`** - behave the same way as **`Ask`** except the location of the provided actor is transparent. This is possible when cluster mode is enabled.
* **`Forward`** - pass a message from one actor to the actor by preserving the initial sender of the message. At the moment you can only forward messages from the **`ReceiveContext`** when handling a message within an actor and this to a local actor.
* **`ForwardTo`** - behave the same as **`Forward`** but when cluster mode is enabled.
* **`BatchTell`** - send a bulk of messages to actor in a fire-forget manner. Messages are processed one after the other in the other they have been sent.
* **`BatchAsk`** - send a bulk of messages to an actor and expect responses for each message sent within a time period. Messages are processed one after the other in the other they were sent. This help return the response of each message in the same order that message was sent. This method hinders performance drastically when the number of messages to sent is high. Kindly use this method with caution.
* **`PipeTo`**  and **`PipeToName`**- send the successful result of a future (long-running task) to self or a given actor. See [PipeTo](/goakt/features/actor/pipeto.md)

## Message Delivery

GoAkt supports **`at-most-once`** delivery: each message handed to the system is delivered either once or not at all. In other words, messages may be lost.

## Deadletters

Messages that cannot be delivered will be sent to the system actor called `deadletter`. One can subscribe to the actor system events stream and receive those messages. See [Events Stream](/goakt/features/events-stream.md).