Existem alguns patterns importantes para usar em sistemas altamente distribuídos como os que o Azure proporciona. A boa nova é que alguns deles já começam a ser divulgados.

O primeiro que vale destacar trata da questão do como atualizar um dado quando milhões de usuários competem para atualizá-lo ao mesmo tempo. Um cenário exemplo é o que acontece nos sistemas de vendas de tickets pela internet.

Por exemplo, semana passada saiu uma notícia do problema nas vendas online de ingressos para o U2 e, ao final, a notícia conta que o uso do Azure fará com que isto não aconteça no Rock in Rio!

Bem, o Azure resolve o problema da escalabilidade, mas não resolve o problema do lock necessário na informação de números de ingressos, por exemplo. Cabe ao arquiteto/desenvolvedor garantir uma estratégia para minimizar o lock e garantir que o sistema não de time out por espera na fila de escrita de um banco de dados.

Um pattern que pode ser encontrado com detalhes neste artigo da MSDN magazine ajuda neste problema. A estratégia do pattern se resume a:

  1. particionar a informação, colocando lotes de tickets (intervalos de números) em registros diferentes (no caso do artigo, blobs). Com isto, diminuímos a concorrência pelo mesmo registro;
  2. uso de concorrência otimista. Isto é, adicionamos um número de versão associado à cada lote e o agente quer for ler e escrever saberá se durante o intervalo entre leitura e escrita houve alguma mudança devido à concorrência. Se não houve, sucesso. Se houve, tenta de novo;

Vale a leitura do artigo.

Outro problema que merece o conhecimento de patterns específicos se refere à falta de um coordenador de transação no Azure. Sem ele, não conseguimos garantir consistência na escrita em mais de um tipo de armazenamento (tabelas, filas, bases de dados, blobs). Pior, não conseguimos ser ACID mesmo quando escrevemos usando um único tipo, como acontece quando executamos escritas em duas tabelas ou dois blobs.

Para tratar disto precisamos de estratégias específicas que podem variar de acordo com a situação.

Um primeiro caso, que permite uma solução simples, é o caso de escrita em uma tabela do Azure de informações do tipo cabeçalho + itens. O livro Moving Applications to Cloud mostra como fazer isto (ver sessão Transactions in aExpense) usando os seguintes truques:

  1. Inserir primeiro todos os itens na tabela de itens usando o batch update (isto é, insere todos de uma vez e de forma transacional, já que todos estão na mesma partição da tabela);
  2. Em seguida inserir o cabeçalho;
  3. Caso haja algum erro na inserção do cabeçalho, os itens serão deletados (desfazimento);
  4. Mesmo assim, existe sempre a possibilidade de haver um crash entre as operações 1 e 2 acima, fazendo o tratamento de erro não rodar. Por isto, de tempos em tempos um processo busca por itens órfãos.

Recomendo a leitura Moving Applications to Cloud, para quem está estudando ou já migrando seu aplicativo para o Azure.

Num post futuro prometo falar de patterns de desfazimento mais genéricos.

Abraços