La arquitectura de software es el conjunto de decisiones estructurales fundamentales sobre un sistema: cómo se organiza en componentes, cómo se comunican entre sí, qué tecnologías se usan y qué restricciones aplican. No es solo un diagrama — es el resultado de trade-offs conscientes que afectan la mantenibilidad, escalabilidad y evolución del sistema.

La arquitectura se enfoca en las decisiones de alto nivel que son difíciles de cambiar después: estructura de componentes, protocolos de comunicación, estrategias de datos. El diseño se enfoca en decisiones de nivel más bajo dentro de esos componentes: patrones de código, clases, interfaces. En la práctica, la línea entre ambos es difusa y depende del contexto.

No. Cualquier desarrollador se beneficia de entender arquitectura. Conocer los trade-offs detrás de las decisiones técnicas te hace mejor programador, te ayuda a participar en discusiones de diseño y te prepara para roles de mayor responsabilidad. Este sitio está diseñado para todos los niveles.

Si sos principiante, empezá por la sección de Fundamentos: conceptos clave, monolito vs microservicios, y APIs. Luego pasá a Patrones para entender las soluciones recurrentes. Si ya tenés experiencia, podés ir directo a las secciones que te interesen o seguir el Roadmap para una ruta estructurada.

Usá microservicios cuando tengas equipos independientes que necesitan desplegar a ritmos diferentes, cuando partes del sistema tienen requisitos de escalabilidad muy distintos, o cuando el dominio es lo suficientemente complejo para justificar bounded contexts separados. Si estás empezando un proyecto nuevo o tenés un equipo pequeño, un monolito bien estructurado suele ser mejor opción.

Empezá con timeouts — es el más simple y el que más impacto tiene. Sin timeouts, un servicio lento puede bloquear toda tu aplicación. Después agregá retries con backoff exponencial para fallos transitorios, y finalmente circuit breaker para protegerte de servicios que fallan de forma sostenida.

No necesariamente. CQRS (separar lecturas de escrituras) se puede implementar sin Event Sourcing, y viceversa. Sin embargo, se complementan bien: Event Sourcing te da un log inmutable de cambios, y CQRS te permite optimizar las lecturas con proyecciones específicas. Evaluá cada uno por separado según tus necesidades.

Las transacciones distribuidas (2PC) intentan mantener consistencia fuerte entre servicios, pero son lentas y frágiles. Las Sagas usan consistencia eventual: cada servicio ejecuta su transacción local y, si algo falla, se ejecutan compensaciones para revertir los cambios. Las Sagas son más resilientes y escalables, pero requieren diseñar las compensaciones cuidadosamente.

Usá ADRs (Architecture Decision Records). Son documentos breves con un formato estándar: contexto, decisión, consecuencias y alternativas consideradas. Guardalos en el repositorio junto al código. Podés encontrar un template en nuestra sección de Templates.

Usá comunicación sincrónica (HTTP/gRPC) cuando necesitás una respuesta inmediata para continuar el flujo. Usá comunicación asincrónica (eventos/colas) cuando el emisor no necesita esperar la respuesta, cuando querés desacoplar servicios, o cuando el procesamiento puede tomar tiempo. En la práctica, la mayoría de los sistemas usan ambas.

Los tres pilares son: Logs (ELK Stack, Loki), Métricas (Prometheus + Grafana) y Trazas distribuidas (Jaeger, Zipkin, OpenTelemetry). Empezá con logging estructurado y métricas básicas. Agregá tracing cuando tengas múltiples servicios y necesites entender flujos end-to-end.

Implementá seguridad en capas: API Gateway para autenticación y rate limiting, JWT/OAuth2 para autorización entre servicios, mTLS para comunicación segura, y secrets management para credenciales. No confíes en la seguridad perimetral solamente — cada servicio debe validar sus propios permisos.

Usá un API Gateway cuando tengas múltiples microservicios expuestos a clientes externos. El gateway centraliza autenticación, rate limiting, transformación de requests y routing. Evitá que los clientes hablen directamente con servicios internos. Para comunicación interna entre servicios, usá service discovery directo.