Merge pull request #52 from megazord/pt-br-corrections

Correct pt-BR translation

README.pt-BR.md

@@ -1,22 +1,21 @@
 O Manifesto Reativo
 ----------------------
 
-Organizações que trabalham em diferentes ramos, estão independentemente descobrindo padrões aleatórios para criarem sistemas que se parecem.
-Esses sistemas são robustos, mais resistentes, muito mais flexíveis e mais direcionado para demandas modernas. 
+Organizações que trabalham em diferentes ramos, estão independentemente descobrindo padrões aleatórios para criarem sistemas semelhantes. Esses sistemas são mais robustos, mais resistentes, mais flexíveis e melhor posicionados para sustentar as demandas modernas.
 
-Essas mudanças estão acontecendo por causa dos requisitos que mudaram drasticamente nos anos recentes. Apenas à alguns anos atrás largas aplicações tinham dez servidores, demoravam segundos no tempo de resposta, várias horas fora do ar para manutenção ou gigabytes de dados. Hoje aplicações são colocadas em produção em quase tudo, desde aplicativos móveis até aplicações na nuvem com clusters rodando milhares de core de processadores. Geralmente os usuários esperam respostas em milisegundos e 100% de disponibilidade. Dados são mensurados hoje em Petabytes. As demandas de hoje simplesmente não comportam as arquiteturas de ontem.
+Essas transformações estão acontecendo por causa dos requisitos que mudaram drasticamente nos últimos anos. Apenas alguns anos atrás, grandes aplicações tinham dezenas de servidores, demoravam segundos para responder, tinham manutenções que demoravam horas e lidavam apenas com gigabytes de dados. Hoje há aplicações em produção em todos os lugares, desde aplicativos móveis até aplicações na nuvem com clusters rodando milhares processadores multi-core. Geralmente os usuários esperam respostas em milisegundos e 100% de disponibilidade. Dados são mensurados em Petabytes. As demandas de hoje simplesmente não são mais atendidas pelas arquiteturas de ontem.
 
-Nós acreditamos que uma abordagem coerente para arquitetura necessária de sistemas, e acreditamos que todos os aspectos necessários já são reconhecidos individualmente: Nós queremos sistemas que são Responsivos, Resiliente, Elástico e Dirigido por Mensagens. Nós chamamos isso de Sistemas Reativos.
+Nós acreditamos que é necessária uma abordagem coerente para arquitetura de sistemas, e acreditamos que todos os aspectos necessários já são reconhecidos individualmente: nós queremos sistemas Responsivos, Resilientes, Elásticos e Orientados a Mensagens. Nós chamamos isso de Sistemas Reativos.
 
-Sistemas criados como Reativos são muito mais flexíveis, Systems built as Reactive Systems are more flexible, desacoplado e [Escalados](/glossary#Scalability). O que faz eles terem uma curva de aprendizagem menor, até mesmo para distribuir e sofrer mudanças.  São significantemente mais fortes para tolerar as [falhas](/glossary#Failure) e quando a falha ocorre elas são fáceis de serem corrigidas com elegância ao invés de desastre. Sistemas Reativos são responsivos, dando  aos [usuários](/glossary#User) uma interação muito mais intuitiva. 
+Sistemas criados como Reativos são muito mais flexíveis, desacoplados e [escaláveis](/glossary#Scalability). Isso os torna mais fáceis de desenvolver e manter. São mais tolerantes a [falhas](/glossary#Failure) e quando elas ocorrem são tratadas com elegância ao invés de desastre. Sistemas Reativos são responsivos, dando aos [usuários](/glossary#User) feedbacks mais interativos. 
 
 *Sistemas reativos são:*
 
-* <a name="Responsive"></a>**Responsivo**: O [sistema](/glossary#System) responde em um tempo hábil se possível. Ser responsivo é a pedra angular da usabilidade e utilidade, mais do que isso, responsividade significa que problemas podem ser detectados rapidamente e tratados com a máxima eficácia.Sistemas Responsivos são focados em fornecer tempos de resposta rápidos e consistentes, estabelecendo limites superiores de confiança para que eles possam entregar um serviço de qualidade. Esse comportamento consiste em simplificar o tratamento de erro, reforça a confiança do usuário final e incentiva futuras interações.
-* <a name="Resilient"></a>**Resiliente**: O sistema continua respondendo em caso de [falha](/glossary#Failure). Isto é aplicável não apenas para sistemas de missão crítica ou para alta disponibilidade — qualquer sistema que não é resiliente vai ficar fora do ar depois de uma falha. Resiliência só é alcançada por [replicação](/glossary#Replication), contenção, [isolação](/glossary#Isolation) e [delegação](/glossary#Delegation). Falhas são contidas com cada [componente](/glossary#Component), isolando os componentes uns dos outros e garantindo que as partes em falhas podem serem recompostas sem parar de servir como um todo. Recuperar cada componente é delegar para outro componente (externamente)  e  alta disponibilidade é garantir a replicação onde seja necessário. O cliente conectado ao componente não pode ser pertubado com questões de falhas.
-* <a name="Elastic"></a>**Elástico**: O sistema continua servindo mesmo em sobrecargas ou variações de carregamento. Os sistemas Reativos podem reagir as mudanças automáticamente reagindo as mudanças de entradas incrementando ou decrementando os [recursos](/glossary#Resource) alocados para servir essas entradas. Isto implica-se em desenhos que não possuem pontos de contenção ou pontos agregados em um só lugar, resultando na habilidade de fragmentar ou replicar componentes e distribuílos. Sistemas Reativos suportam prevê, assim como Reage, escalando algoritmos e promovendo mensuração e performance em tempo real. Conseguem [elasticidade](/glossary#Elasticity) de uma forma eficaz em termos de custos em hardware e plataformas de software.
-* <a name="Message-Driven"></a>**Dirigido por mensagem**: Sistemas Reativos tem como base Assincronidade, precisam ser [Assíncronos](/glossary#Asynchronous) [passagem de mensagem](/glossary#Message-Driven) para estabelecer um círculo entre componentesto que garantem baixo acoplamento, isolamento, [transparência na localização](/glossary#Location-Transparency), e fornece meios de delegar[erros](/glossary#Failure) como mensagens. Empregando a passagem de mensagens explicitamente o que permite habilidades como, gerencimaneto do carregamento, eslasticidade e fluxo de controle por meio de mapeamento e monitoramento da fila de mensagens pelo sistema e aplicando [sobrecargas](/glossary#Back-Pressure) quando necessárias. A transparência na localização das mensagens como um meio de comunicação torna possível para o tratamento da insuficiência de trabalhar com as mesmas construções e semânticas em um cluster ou dentro de um único host. Comunicações [não bloqueadas](/glossary#Non-Blocking) se comunicam com os destinatários, permitindo-os apenas consumir os [recursos](/glossary#Resource) enquanto ativo, deixando o sistema menos sobrecarregados.
+* <a name="Responsive"></a>**Responsivo**: O [sistema](/glossary#System) responde em um tempo hábil se possível. Ser responsivo é a pedra fundamental da usabilidade e utilidade, mas mais do que isso, responsividade significa que problemas podem ser detectados rapidamente e tratados com a máxima eficácia. Sistemas Responsivos são focados em fornecer tempos de resposta rápidos e consistentes, estabelecendo limites superiores de confiança para que eles entreguem qualidade de modo consistente. Esse comportamento consiste em simplificar o tratamento de erro, reforçar a confiança do usuário final e incentivar futuras interações.
+* <a name="Resilient"></a>**Resiliente**: O sistema continua respondendo em caso de [falha](/glossary#Failure). Isto é aplicável não apenas para sistemas de missão crítica ou para alta disponibilidade — qualquer sistema que não é resiliente ficará fora do ar depois de uma falha. Resiliência é alcançada por [replicação](/glossary#Replication), contenção, [isolamento](/glossary#Isolation) e [delegação](/glossary#Delegation). A contingência a falhas é feita dentro de cada [componente](/glossary#Component), isolando-os uns dos outros e assim garantindo que partes do sistema podem falhar e se recuperar sem comprometer o sistema como um todo. A recuperação de cada componente é feita por outro componente (externo) e alta disponibilidade e garantida por replicação quando necessário. Os clientes de cada componente não são sobrecarregados com o tratamento de falhas.
+* <a name="Elastic"></a>**Elástico**: O sistema continua responsivo mesmo sob variações de demanda. Sistemas Reativos podem reagir a mudanças na taxa de entrada através do aumento ou diminuição dos [recursos](/glossary#Resource) alocados para lidar com essas entradas. Isso requer projetos que não tenham pontos de contenção ou gargalos centrais, resultando na habilidade de dividir ou replicar componentes e distribuir a demanda entre eles. Sistemas Reativos suportam algoritmos de escalonagem preditivos, assim como Reativos, provendo métricas relevantes e em tempo real. Eles conseguem [elasticidade](/glossary#Elasticity) com custo efetivo em hardware padrão e em plataformas de software.
+* <a name="Message-Driven"></a>**Orientado a Mensagens**: Sistemas Reativos usam [passagem de mensagens](/glossary#Message-Driven) [assíncronas](/glossary#Asynchronous) para estabelecer fronteiras entre os componentes e garantir baixo acoplamento, isolamento, [transparência na localização](/glossary#Location-Transparency) e provêem meios para delegar o tratamento de [erros](/glossary#Failure) através de mensagens. Empregar explicitamente a passagem de mensagens, modelar e monitorar as filas do sistema e aplicar [contrapressão](/glossary#Back-Pressure) quando necessário, permite gerenciamento de demanda, elasticidade e controle de fluxo. Mensagens com transparência na localização como um meio de comunicação tornam possível o gerenciamento de falhas da mesma maneira seja em um cluster ou em um único host. Comunicação [não bloqueante](/glossary#Non-Blocking) permite que destinatários consumam [recursos](/glossary#Resource) quando ativos, evitando desgaste do sistema.
 
-Grandes sistemas são compostos por pequenos serviços e portanto, dependem das propriedades reativas de cada um deles. Isto significa dizer que Sistemas Reativos não foge da regra dessas regras e se aplica a todos os níveis de escalonamento, fazendo com que eles se baseiam se tornem compostos.Grandes sistemas no mundo tomam como base nessas propriedades e servem as necessidades de bilhões de pessoas todos os dias. Está na hora de aplicar esses princípios conscientemente do início ao contrário de redescobri-los a cada hora.
+Grandes sistemas são compostos por pequenos serviços e portanto, dependem das propriedades Reativas de cada um deles. Isso significa que Sistemas Reativos usam principios de projeto para que essas propriedades se apliquem em todos os níveis e escalas, tornando-os combináveis. Os maiores sistemas do mundo são arquitetados com base nessas propriedades e servem as necessidades de bilhões de pessoas diariamente. Está na hora de aplicar esses princípios conscientemente do início ao contrário de redescobri-los a cada hora.
 
-[Assine o manifesto reativo](http://www.reactivemanifesto.org/pt-BR#sign-button)
+[Assine o manifesto reativo](http://www.reactivemanifesto.org/pt-BR#sign-button)