Alpha's Manifesto

A black and white figure's thought-hive

CQRS

Estuve leyendo un poquito últimamente sobre CQRS, que significa Command-Query Responsibility Segregation en inglés (sería “Segregación de responsabilidades de commands-queries” en español, ahora explicaré). No he encontrado una buena y corta explicación al respecto así que aquí va mi intento:

¿Qué significa?

Llamaremos Command (comando) a cada operación en nuestro sistema que impactará el estado de la aplicación. Esto significa, cualquier acción que vaya a llevar un cambio en nuestros datos. (Recuerden, el comportamiento puede ser modelado como datos también, pero podemos considerar estos casos como un subconjunto de las situaciones de las que estamos hablando.) Por ejemplo, agregar un usuario, eliminar una tarea, cambiar un registro o actualizar los permisos pueden ser vistos como commands. Si están familiarizados con el patrón de diseño Command, pueden pensar que esta es la forma correcta de representar estas acciones. La idea encaja correctamente, pero estamos hablando de un modelo arquitectural aquí, así que aunque parezca natural usar este patrón, no es realmente necesario.

Llamaremos Query a cada operación que lea de nuestros datos para devolver un resultado. Por ejemplo, verificar si un cierto nombre de usuario existe, o traer una lista de tareas, verificar si un usuario tiene permisos, etc. Recuerden que las queries no alteran los datos. Como pueden ver, estos pueden ser modelados como un tipo de patrón de diseño command nuevamente, pero no es el punto de este artículo.

Finalmente Segregación de la Responsabilidad (otros usan Separación en su lugar) significa que nuestra aplicación usará comnands y queries de forma separada, y que no pueden ser mezclados. Esto significa que nuestro sistema realizará operaciones de escritura y de lectura en tiempos o en espacios lógicos separados.

¿Para qué sirve?

La mejor aproximación para este patrón arquitectural es tener dos conjuntos de datos distintos, uno para lectura y otro para escritura. El de escritura (view data source) está basado en el otro, que podría ser la persistencia actual para nuestros datos. Podemos entonces mejorar nuestro conjunto de datos para la lectura (que no tiene por qué ser relacional, ni normalizado, ni siquiera persistente mientras esté disponible, como un tipo de caché) para tener una aplicación muy veloz, mientras que el trabajo serio se hace con los commands en el otro conjunto de datos.

Las aplicaciones orientadas a tareas pueden entonces delegar las acciones de forma asíncrona para que las tareas-commands (escritura) no ocurran en tiempo real, así permitiéndonos tratar la concurrencia fácilmente, o dando una experiencia increíble en la sensación de velocidad en la aplicación de usuario. Han visto el mensaje de “Enviando email” de GMail y cómo a veces es instantáneo y otras veces puede tardar hasta 30 segundos? Ese es el tipo de experiencia que podrían dar.

El artículo en donde leí esto (MSDN: CQRS on Windows Azure) explica cómo los comandos pueden ser encolados para ser procesados por un thread en segundo plano, de forma que las tareas no tienen que mantener al usuario esperando, y un segundo thread en segundo plano puede estar actualizando los datos para la vista (los que usan las queries para leer), también de forma asíncrona. Nuestra aplicación podría ser la más rápida para la experiencia del usuario, o podríamos tener al usuario esperando y er notificado cuando su tarea se ejecuta (algo como un panel de notificaciones en la aplicación, algo al estilo Facebook que diga “Su reservación ha sido procesada” mientras el usuario sigue navegando por el sitio, quizás?).

Suena demasiado bueno para ser verdad…

Bueno, esta aproximación tiene sus problemillas. Número uno, definitivamente no lo recomendaría para sistemas de misión crítica o de tiempo real. Para nada. De ninguna manera.

Número dos, y tres, cuatro, cinco, etc., es que nos encontramos forzados a proveer un tipo especial de experiencia de usuario en donde las cosas no ocurren en tiempo real. ¿Cómo manejar esto?

Manejando operaciones de forma asíncrona

Al mismo tiempo, hay un problemita cuando necesitamos que nuestras queries funcionan contra datos reales, en tiempo real. Y a veces, no podemos evitar esto. Por ejemplo, ¿qué si necesitáramos hacer validaciones en un nombre de usuario que el usuario nos provee para verificar que no está duplicado? (Por supuesto, podemos diseñar las estrategias de caché para eso, pero aún así, es un problema.) Este tipo de situaciones puede llevar a algunas impurezas en el diseño, ya que deberíamos trabajar contra nuestro conjunto de datos de persistencia, y no el de lectura, pero las aplicaciones pueden ser modeladas en una forma diferente bajo la premisa de nada es urgente. Miremos algunos ejemplos:

  • ¿Es el nombre de usuario único?
    ¿Por qué necesitaríamos nombres de usuario? Usemos email, autenticación externa como Facebook, Twitter, Google, Windows Live, OpenID, etc. No hagamos que el flujo de usuario dependa de un dato.
  • ¿Están los lugares disponibles para reservación?
    Hagamos un query sobre los datos de lectura, digámosle al usuario que puede haber cambios basado en su pedido, que está viendo y que se le enviará una notificación en el futuro avisando si la reservación fue exitosa o no. Hagamos una reservación lo más cercana a lo que el usuario prefería y permitámosle cambiarla luego, etc.
  • Verificar información de pago
    El pago es nunca instantáneo. Permitámosle al usuario proveer algún tipo de información de contacto, y si el pago no ocurre, contactémoslo luego. Avisémosle más tarde si el pago se efectuó o no. Podríamos en el tiempo intermedio darle una membresía temporal o limitada, etc.
  • Mensajería
    A menos que nuestro sistema de mensajería debiera trabajar como un chat en tiempo real, siempre puede ser procesado con determinada espera. En un chat, la gente espera que los mensajes lleguen de forma instantánea, pero con mensajes siempre saben que las esperas son posibles.

Hay muchos otros ejemplos. A menos que estemos trabajando en un sistema de tiempo real, muchas de las tareas pueden ser trabajadas en otro punto del tiempo. Nuevamente, si no estamos trabajando sobre un sistema de RADAR para el ejército.

Resumen

CQRS (Command-Query Responsibility Segregation/Separation) nos permitirá trabajar de forma asíncrona con operaciones de datos, que a veces pueden tomar más de lo esperado. El impacto más importante en esta aproximación son las expectativas que debemos darle al usuario sobre cuándo se ejecutarán las operaciones, pero la parte buena es la estabilidad, velocidad y disponibilidad de nuestra aplicación. Esto nos provee de habilidades especiales para escalar y crecer en las características de la misma.

Más referencias

  • Domain queries in CQRS, Stack Overflow
    Situaciones de tiempo real, aproximaciones a ellas en una aplicación CQRS.
  • CQRS,  Task Based UIs, Event Sourcing, agh!, CodeBetter.com
    Este artículo habla de CQRS como patrón de diseño, no como patrón arquitectural. Personalmente no me encuentro en deacuerdo con eso, pero es un muy buen artículo.
  • Clarified CQRS, Udi Dahan
    Un buen artículo explicando CQRS y qué hacer en situaciones específicas.
  • CQRS on Windows Azure, MSDN Magazine
    La versión cloud de CQRS.

Link del día: Un mundo de Tweets

Aplicaciones para Twitter abundan. Aplicaciones o reportes o análisis que toman información estadística desde Twitter, también. Pero pocas realmente se distinguen de otras, o son novedosas, o tienen algo que las hacen especiales.

Este es el caso de una aplicación que basándose en los datos de Twitter, es especial. La aplicación se llama A World Of Tweets. Es un sistema que en tiempo real nos mostrará cuales son las zonas más candentes de tweets y en qué puntos del mapa se está actualizando más la información en esta plataforma. Por supuesto, también nos dará algunos datos a nivel estadístico por país, por región, o por fecha.

Cabe destacar que A World of Tweets nos mostrará un mapa codificado en colores (o en nubes oscuras, si así lo elegimos) para mostrar mayor actividad, podemos ver el mapa político o físico, y por si eso no fuera poco, podemos verlo en 3D. Sí señores, en 3D, sólo tenemos que tener nuestros anteojos azules y rojos preparados para poder apreciar a Twitter invadiendo el mundo en tiempo real y en tres dimensiones.

Soy un zorrinito twittero.

Doppler Reports (Español)

Hola a todos

Me enorgullece poder anunciar que desde hace un tiempo he tenido la oportunidad de trabajar junto con el equipo Doppler para un nuevo proyecto, algo que desde entonces se estaba formando llamado Doppler Reports (link). Este proyecto finalmente vio la luz y está activo públicamente desde el 27 de Julio. Permítanme contarles un poco más sobre eso.

Momento… ¿qué es Doppler?

Doppler Email MarketingPara aquellos que no lo conocen, Doppler es una herramienta de email-marketing. Es realmente compleja, pero explicándola en un vistazo rápido, es posible usarla para crear contenido de email online (basado en plantillas o editandolo manualmente), y enviarlo masivamente a una o más listas pre-cargadas. Sim embargo, hay mucho más para lo que puede utilizarse, y una de las grandes posibilidades que nos ofrece está en la capacidad de analizar la reacción del cliente a nuestras campañas de emails. Cuando uno tiene diez, quizá veinte, cincuenta o cien contactos, esto es algo que se puede hacer fácilmente con un listado de ellos. Uno verifica sus contactos, analiza quién abrió los emails enviados, quién hizo click en cuál link, y esa es toda la información que uno necesita.

¿Reportes?

Las cosas cambiaron mucho desde esa mañana del 2005. ¿Qué pasa cuando tienes mil contactos? ¿Y un millón? No, no estoy exagerando. Eso es parte de nuestro trabajo *diario*: mantener una herramienta que envía millones de emails. ¿Cómo obtenemos los resultados y los mostramos al usuario? La respuesta obvia es: Reportes.

Los reportes  te darán toda la información resumida que necesitas sin tener que revisar cada uno de los contactos (porque, por supuesto, el sistema lo hace por tí). A medida que la tecnología evoluciona y que el comportamiento del cliente evoluciona a medida que el marketing evoluciona, nuestras herramientas deben evolucionar también.

Aquí es donde el Equipo de Doppler vio la necesidad de una aplicación de reportes totalmente nueva, para poder satisfacer muchos pedidos que nuestros clientes tenían para la versión anterior de la misma. Pero esta herramienta debía estar pensada para millones de emails, miles de usuarios, información en tiempo real y al mismo tiempo, reportes informativos y elegantes.

Y entramos en la escena. Tuve la oportunidad de trabajar junto con Juan Fazzini para diseñar una arquitectura que escalaría a medida que Doppler siguiera creciendo con todas las futuras características que obtendrá. Entonces, en una tarde de viernes, un pizarrón en blanco, una notebook como grabadora para todo lo que decíamos (ya saben, la documentación es importante), comenzamos a idear y pensar sobre cómo Doppler Reports trabajaría.

¿Cómo está diseñada la arquitectura?

1. Arquitectura distribuida

Distributed architectureCada parte de Doppler funcionará como un módulo independiente, que puede tener varias instancias funcionando al mismo tiempo. Hay un módulo en especial que se encargará de interconectar a los demás entre ellos, pero estos módulos de interconexión pueden trabajar de forma independiente también.

Esto significa que ahora tenemos mayor tolerancia a errores catastróficos. Si un servidor deja de funcionar, las otras instancias de los módulos seguirán trabajando, manteniendo al sistema con funcionamiento normal. Los usuarios no se darán cuenta, apenas puede que noten una demora pequeña en la aplicación.

También significa que si tenemos mucha carga por uso intensivo, podemos crear nuevas instancias de un módulo y los módulos de interconexión automáticamente balancearán la carga.

2. Seguridad en cada llamada

Keys and lock

Tener estos módulos ahí afuera no es poca cosa para la seguridad. La seguridad tiene que ser tan estricta como es posible. Por eso, desarrollamos un protocolo de comunicación que le permitiría a cada módulo verificar si el que llama al mismo es una aplicación autorizada y si está bien devolver datos a la misma. Si todo funciona bien, la llamada se realiza y los datos se devuelven. Si algo no sale bien, como si se provee un token de autorización incorrecto, nunca se sabrá qué pasó. Sabemos que esto no es particularmente transparente para los programadores, pero es lo más seguro que podemos realizar para prevenir intentos de hacking.

El resultado de esta característica es que, incluso cuando los módulos estén disponibles en Internet (no todavía, pero quizás en algún momento lo estén), no cualquiera puede acceder a ellos. Incluso si saben en dónde están o cómo llamarlos, ellos no harían nada hasta que los clientes le provean un token de seguridad auténtico.

También significa que las claves de seguridad para acceder a este módulo se pueden generar y, en el futuro, podría resultar en una API para ciertos módulos de Doppler que cualquiera (o algunos usuarios) podrían utilizar. ¿Imaginas crear una aplicación para tu propia empresa que automáticamente trabaje con los datos que Doppler generó para tí?

3. Reportes en tiempo real

Más que una decisión arquitectural, esto fue un desafío. Ya se sabe que estamos manejando toneladas de datos. ¿Cómo cargarlos rápidamente? ¿Cómo obtener una buena performance? Para eso, decidimos que algunos objetos trabajarían internamente como proxies, de forma que sólo se obtendría la información que se ve.

Esto significa que ahora al entrar a la pantalla de Resumen de Métricas para una de tus campañas, podrías ver (cuidado… se viene un listado grande):

Quick clock

  • Nombre de la campaña
  • Asunto del email de la campaña
  • Tipo de campaña
  • Cantidad de listados de emails que recibieron la campaña
  • Cuántos suscriptores recibieron la campaña
  • Cuándo se envió la campaña
  • Aperturas por cada hora
  • Clicks por cada hora
  • Cuántos emails fueron abiertos (total)
  • Cuántos emails todavía no han sido abiertos
  • Cuántos emails resultaron en soft-bounce
  • Cuántos emails resultaron en hard-bounce
  • Última fecha de apertura
  • Clicks únicos
  • Aperturas únicas
  • Cada uno de los links
  • Para cada link, cuántos suscriptores hicieron click en ellos
  • Para cada país del mundo, cuántas aperturas ocurrieron en ese país

*toma aire* ¿Saben cuánto tiempo le toma a Doppler Reports obtener y mostrar toda esa información? Menos de 5 segundos. Pongo énfasis en ello: Menos. De. Cinco. Segundos. Ese es el tiempo que me toma leer las primeras tres líneas de la página. Quizá cuatro, quizá cinco. Pero antes de que haya terminado de hacerlo, la página está completamente cargada y funcionando. Y debo aclarar, mi conexión a internet no se destaca por su velocidad.

Por supuesto, también usamos caching. Esto agrega una capa más de interacción hasta los datos, pero nuestro sistema de caching nos asegura que tengamos los datos listos para el usuario en el momento que los pida. Los datos de una campaña no cambian mucho, a menos que se acabara de enviar, por lo que, para la gran mayoría de los casos, podrías ver los datos de tu campaña tan rápido como cualquier otra página web.

4. Diseño modular

Puzzle

Mencioné antes que Doppler ha comenzado a ser más y más complejo, y ahora está siendo diseñado de una forma modular. De esta forma, los módulos trabajan independientemente y a la vez, delegan responsabilidad en el módulo que sabe cómo resolver un cierto problema o cómo tratar cierto conjunto de datos. Tener un diseño modular es un aspecto terriblemente importante para cambios futuros. Le permite a nuestro equipo paralelizar el trabajo, y le permite a nuestro equipo (y a nuestra aplicación) crecer.

Esto tiene importantes consecuencias. Para el lado que el usuario logra ver, esto significa que muchas características estarán disponibles más rápidamente. Nuevas características, más mejoras, más robusto, más rápido, mejor. “Harder, faster, better, stronger.”, como Daft Punk recomienda construir el software.

Eso es increíble, ¿puedo usarlo?

Por supuesto. Estas nuevas características ya están disponibles para todos los usuarios que tengan una cuenta de Doppler. Si no tienes una, puedes crearte una de forma gratuita y probar el producto por tí mismo: http://www.FromDoppler.com/.

Antes de que se vayan…

…Quería decir que considero un logro personal haber podido formar parte de todo esto. Intentamos lograr algo radical y hoy tenemos un producto radical. Creo que el Equipo Doppler está muy orgulloso de lo que han logrado. Yo ciertamente lo estoy.

Ah, y este post ha llegado hasta el blog de GetCS. Visitenló, puede que les interese.

Doppler Reports

Hello to you all

I’m really glad to announce that since some time ago, I had the opportunity to work along with the Doppler team for a new project, something that since that time was evolving, called Doppler Reports. This project finally became active and working publicly on July 27th. Let me tell you a little more about it.

What is Doppler anyway?

Doppler Email MarketingFor those that are not aware of it, Doppler is a online email-marketing tool. It’s really complex, but explaining it just at a glance, you can use it to create email content online (template-based or editing it yourself online), and sending it massively to one or many of your pre-entered mailing lists. However, there is much more to it, and one of the big powers enclosed in such a tool is the ability to analyze the customer’s reaction to your mail campaigns. When you have ten, maybe twenty, fifty, or even a hundred customers, this is something you could easily do with lists. You check for your contacts, you see who opened the email you sent, you see who click on which link, and that’s all the information you need to go on.

Reports?

Things have changed a lot in the business since that morning in 2005. What happens when you’ve got a thousand contacts. A million? No, I’m not exagerating. That’s part of our everyday work, maintaining a tool that daily sends millions of emails. How do we get results and present them to the users? The obvious answer is: reports.

Summarizing reports will give you the information youneed without having to scan for each of your contacts (because, of course, the system does it for you). And as technologies evolve, and as customer behavior evolves, and as marketing evolves, our tools needs to evolve too.

That’s where the Doppler Team saw the necessity of creating a new brand report application, in order to fulfill a lot of requests that our customers had from the previous version of our reporting tool. But this one would have to be thought for millions of emails, thousands of users, real time information and at the same time elegant and data-rich reports.

Then we entered the scene. I had the chance to work closely along with Juan Fazzini to design an architecture that would scale as Doppler would get bigger with all future features that it will get. So, in a Friday afternoon, a big white board, a notebook as recorder to keep track of everything we said (you know, documentation is important), we started brainstorming and dreaming about what Doppler reports would work like.

How is the architecture designed?

1. Distributed architecture

Distributed architectureEvery part of Doppler will work as a separated module, that can have many instances working at the same time. There is a special module which will take care of connecting all of the others between them, but these interconnection modules may work independently as well.

This means that we now have more catastrophic-error tolerance. If one server fails down, the other instance of the module will keep on working, and users will notice nothing, but maybe some little delay on the application.

This also means that if we have too much load, because of intensive use, we can just create new module instances and the interconnection modules load balancing will automatically take care of the load.

2. Security on each call

Keys and lockHaving this modules out on the wild is no little thing for security. So, security had to be strong as possible, and we developed a communication protocol that would allow each module to check if the caller is in fact an authorized application and that it is ok to return data to it. If everything goes right, then the call is made and the results are returned. If something goes wrong, as like if you provided an incorrect token, you would never know what happened. This is not transparent at all for the end developer (and we know that), but it is as secure as it gets to prevent hackers.

This means that even when modules are out in the internet (not right now, but maybe someday), not anyone can access them. Even if they knew where they are and how to call it, it would just do nothing until clients provide an authorized token.

This also means that the keys that allow access to this module can be generated and in the future, the API for certain Doppler modules would be available for everyone (or just some users) to use. Do you imagine creating an application for your business that would automatically work with the data Doppler generated for you?

3. Real time reports

More than an architectural decision, this was a challenge. You already know that we are handling tones of data. How to load it quickly, how to achieve a high performance? For that, we decided to make some internal objects proxy-like, so that you would only get the information you request.

This means that you can now enter the dashboard screen summary report for one of your campaigns, and you would see (beware… long list coming):

  • Quick clockName of the campaign
  • Subject for the campaign
  • Campaign type
  • Amount of mailing lists that received that campaign
  • How many unique subscribers received
  • When was the campaign sent
  • Total openings by hour
  • Total clicks by hour
  • How many mails where opened (total)
  • How many mails haven’t been opened yet
  • How many mails have soft-bounced
  • How many mails have hard-bounced
  • Last open date
  • Unique clicks
  • Unique opens
  • Last click date
  • Each of the links
  • For each of the links, how many subscribers clicked on them
  • For each country in the world, how many openings happened in that country

*breathes for air* Do you know how much time takes to Doppler Reports gather and show all that information? Less than 5 seconds. Let me emphasize that: Less. Than. Five. Seconds. That’s what takes me to read the first three lines of the page. Maybe four, maybe five. But before I finished doing that, all the page is completely loaded and working. And I have to say, mine is not a premium connection.

Of course, we also use caching. This adds another layer of interaction until we get to the data, but our caching framework provides us with the ability of habing the data ready for the user right away. Campaign data does not change very often unless you have just sent it, so for most of the cases, you will be able to check your campaign data as quick as any webpage would load up.

4. Modular design

PuzzleI mentioned before that Doppler had started to become more complex, and is now being designed with a modular approach. In this way, modules work independently and at the same time, they rely responsibilities on the module that really knows how to solve a certain problem, or to treat certain data. Having a modular design is terribly important for future changes. It allows our team to parallelize work, it allows our team (and application) to grow.

This has great consequences. On the users side, new features will be available sooner. New features, new improvements. Harder, faster, better, stronger. (As Daft Punk suggests we build our software.)

That impresses me, may I use it?

Of course, this new features are available to all users that have a Doppler account. If you don’t have one, you can even create one free and try the product for yourself: http://www.FromDoppler.com/

Before you go…

…I just want to say that I consider a personal achievement having been part of all of this.  We tried to do something radical, and we have a radical product today. I think that all of the Doppler Team is very proud of what they have today, and I sure am too.

Oh, and this post has made its way into the GetCS blog. Make sure to check it out.