La polisemia, en el contexto de la arquitectura de sistemas, describe la situación donde un elemento (como un identificador, un tipo de mensaje, un campo de datos o incluso un concepto de negocio) posee múltiples significados o funciones que varían según el subsistema, el contexto operativo o la fase del ciclo de vida. No se trata de ambigüedad por diseño deficiente, sino de una reutilización intencionada o emergente de un mismo 'símbolo' para representar diferentes 'semánticas' en dominios distintos pero interconectados. Esto puede manifestarse en APIs donde un parámetro tiene un significado en una operación y otro en otra, o en sistemas de mensajería donde un 'evento' puede desencadenar flujos completamente diferentes en microservicios distintos.
Un ejemplo común de polisemia se encuentra en los sistemas de 'event-driven architecture' (EDA) o 'message queues'. Un 'evento' como 'OrderUpdated' puede ser interpretado de manera polisémica: para el servicio de facturación, significa que debe recalcular el total; para el servicio de inventario, puede significar que se liberaron o reservaron ítems; y para el servicio de notificaciones, que debe enviar un email al cliente. Otro ejemplo es el uso de 'tags' o 'labels' en sistemas de orquestación como Kubernetes, donde una misma etiqueta puede ser usada para seleccionar pods para un servicio, para aplicar políticas de red o para programar cargas de trabajo en nodos específicos, cada uno con una semántica diferente para el componente que la consume. En bases de datos NoSQL, un campo 'status' puede tener valores que significan cosas distintas en diferentes colecciones o documentos, aunque el nombre del campo sea el mismo.
Para el arquitecto, la polisemia es una espada de doble filo. Por un lado, puede promover la reutilización y reducir la proliferación de nuevos identificadores, simplificando aparentemente el modelo de datos o de eventos. Por otro lado, introduce una complejidad cognitiva significativa y aumenta el riesgo de errores si los contextos no son manejados explícitamente y con rigor. Un arquitecto debe evaluar si la polisemia es una optimización legítima (ej. un identificador global que se especializa localmente) o una 'technical debt' disfrazada. Es crucial documentar exhaustivamente los diferentes significados y contextos, y considerar patrones como 'Context Bounding' de Domain-Driven Design para delimitar explícitamente dónde un término adquiere un significado particular. Ignorar la polisemia puede llevar a acoplamientos ocultos, dificultades en el debugging y una escalabilidad cognitiva reducida para los equipos de desarrollo.