/* Page prose (es) */
"DistributedWrappingUp" = "# Resumen\n\nUn **actor distribuido** es el actor que ya conoces con una red dejada caer en el medio. Ese único cambio se propaga a todo lo de abajo, y nada de ello puede desearse para que desaparezca. Lee las conclusiones como un solo argumento continuo de por qué un `actor` local es casi siempre la primera respuesta correcta.\n\n* Un **actor distribuido** extiende el modelo del `actor` local a través de procesos y máquinas: la misma sensación de `await`-para-llamar, pero la llamada puede cruzar una red.\n* Se apoya en cuatro piezas: el **`distributed actor`**, sus métodos **`distributed`**, un **`ActorSystem`** (el transporte que localiza a los actores y transporta mensajes), y un **`ID`** serializable que hace a un actor localizable desde lejos.\n* Las llamadas distribuidas son `async` **y** `throws`. El `try` está ahí porque la red puede fallar de verdad: tiempos de espera agotados, conexiones caídas, un nodo caído. Diseña para llamadas que no vuelven, en lugar de tratar el fallo como una sorpresa rara.\n* Los argumentos y valores de retorno deben ser **`Codable`**, porque viajan como bytes: `Sendable` del capítulo [Actores globales y Sendable](Global%20Actors%20and%20Sendable.playgroundchapter/Overview) llevado un paso más allá. Diseña las cargas útiles como tipos de valor pequeños y autocontenidos (como `Receipt`), no como objetos en vivo o referencias.\n* La **transparencia de ubicación** te deja llamar a un actor de la misma forma dondequiera que viva, pero los costos son reales: latencia (envía mensajes menos numerosos y más grandes), fallo parcial, y serialización. Diseña teniéndolos en cuenta.\n* Para la mayoría de quienes desarrollan apps esta es una necesidad *rara*, más relevante para Swift del lado del servidor y sistemas agrupados. No distribuyas un sistema que cabe cómodamente en un proceso; entender el modelo importa más que usarlo a diario.\n\n[Anterior](@previous)  |  página 9 de 9";
