Las dos caras de la abstracción en diseño de sistemas: ocultar o reducir

Fuentes: The Two Abstractions of System Design: Hide or Reduce

En ingeniería de software se utiliza la palabra "abstracción" para designar dos prácticas muy distintas que suelen confundirse. Un análisis publicado por el blog técnico Muratbuffalo distingue entre la abstracción de modularidad, herencia de la carrera de ciencias de la computación, y la abstracción de modelado, propia de los métodos formales y la matemática aplicada.

La primera, enseñada mediante tipos abstractos de datos, APIs y diseño por capas, consiste en encapsular los detalles internos tras interfaces estables. Su propósito es ocultar: esconder el disco bajo el sistema de archivos, la red bajo NFS, los planes de ejecución bajo SQL o el MMU bajo la memoria virtual. Funciona, pero, como recordó Joel Spolsky, todas estas abstracciones terminan siendo leaky.

La segunda opera en sentido contrario: no oculta, sino que recorta. Parte de un sistema completo y conserva únicamente el comportamiento mínimo indispensable para demostrar una propiedad. Elimina lo accesorio y conserva solo la esencia, incluso exponiendo lo que la primera abstracción taparía, como la concurrencia. El objetivo no es construir un módulo fácil de usar, sino extraer el máximo de concurrencia segura de un diseño.

El texto ilustra esta idea con ejemplos de sistemas distribuidos: los relojes lógicos de Lamport prescinden del tiempo de reloj y conservan solo la relación happened-before; la linealizabilidad descarta replicación, caché y reintentos; la idea de "el log es la base de datos" descarta el estado materializado; y MapReduce ignora orquestación y tolerancia a fallos para quedarse con un DAG de transforms deterministas. En todos los casos, la potencia del diseño procede de eliminar lo ortogonal a la propiedad que se quiere preservar, no de esconderlo tras una interfaz.