Downloaded 16 times
Uploaded byBruno Oliveira
Qconsp domesticando dragoes com soluções escaláveis
The document discusses the challenges of building a scalable SMS notification system. An initial pilot system could only handle 3 transactions per second, but production needs were over 17 transactions per second with peaks of 200 per second. To solve this, the system was improved by using message queues and a Redis cache to handle the higher volumes and meet the client's needs.
Qconsp domesticando dragoes com soluções escaláveis
- 1. Domesticando Dragões com soluções escaláveis @abstractj @qmx Monday, September 13, 2010
- 2. O cliente pediuum sistema Monday, September 13, 2010
- 3. Envio de SMSpela intranet + aplicacao web pra ver detalhes da mensagem Monday, September 13, 2010
- 4. A cláusula “O sistema deve fazer tudo” Caso de uso, 2004 Monday, September 13, 2010
- 5. Teu chefe Monday, September13, 2010
- 6.
- 7.
- 8. SEU EMO!!!! Monday, September13, 2010
- 9. Sistema em piloto 10.000 tx/h = quase 3 tx/s Monday, September 13, 2010
- 10. Bonito e Performático Monday,September 13, 2010
- 11.
- 12. A volta dosque não foram Monday, September 13, 2010
- 13. A cláusula “O sistema deve fazer tudo” Caso de uso, 2004 Monday, September 13, 2010
- 14.
- 15. O legado Monday, September13, 2010
- 16.
- 17. Legado = Mainframe Monday,September 13, 2010
- 18.
- 19.
- 20. Não gosta dosseus dados Monday, September 13, 2010
- 21. Não quer trabalharpra você Monday, September 13, 2010
- 22. Não espera, você espera Monday, September 13, 2010
- 23. te odeia Monday, September13, 2010
- 24. Mainframe não escala Monday,September 13, 2010
- 25. Mainframe não escala? Monday,September 13, 2010
- 26.
- 27.
- 28.
- 29. Ainda bem Monday, September13, 2010
- 30.
- 31. Flat files? Monday, September13, 2010
- 32.
- 33. Filas de Mensageria! Monday,September 13, 2010
- 34. Problema resolvido! 3 tx/s Monday, September 13, 2010
- 35. A cláusula “O sistema deve fazer tudo” Caso de uso, 2004 Monday, September 13, 2010
- 36. Projeto piloto 3 tx/s = Bom Monday, September 13, 2010
- 37. Realidade: 1.5M tx/dia = 17tx/s Monday, September 13, 2010
- 38. Estamos devendo: ± 1.25M tx Monday, September 13, 2010
- 39. "Compra de R$5000,00 realizada com sucesso em 10/09/2010 03:56" 12/09/2010 15:30 Monday, September 13, 2010
- 40. Murphy: se vocêcorria risco de fraude, ela aconteceu com certeza Monday, September 13, 2010
- 41.
- 42. Pico de 200tx/sna hora do almoço Monday, September 13, 2010
- 43. E agora? Monday, September13, 2010
- 44. Onde foi queeu errei? Monday, September 13, 2010
- 45. Você é culpado Monday,September 13, 2010
- 46. Na média, o ser humano tem uma bola Monday, September 13, 2010
- 47. Você perguntou pro seu cliente quais eram os horários de pico?! Monday, September 13, 2010
- 48. Sua obrigação eramedir!!! Monday, September 13, 2010
- 49. Sua aplicação escala?! Monday,September 13, 2010
- 50. Você vai atéonde na vertical?! Monday, September 13, 2010
- 51. E na horizontal?! Monday,September 13, 2010
- 52. Você não está esquecendo de nada? Monday, September 13, 2010
- 53. Visualizar os detalhes da mensagem Monday, September 13, 2010
- 54. Ruby é lento? Monday,September 13, 2010
- 55. A culpa éde quem? Monday, September 13, 2010
- 56. Banco de dados? Monday,September 13, 2010
- 57. Massa de dadosgrande Monday, September 13, 2010
- 58. 1.500.000 x 30dias Monday, September 13, 2010
- 59. Em um mês 45 milhões de registros Monday, September 13, 2010
- 60. preciso guardar tudo isso? Monday, September 13, 2010
- 61. relacional pra quê? Monday,September 13, 2010
- 62.
- 63.
- 64.
- 65. Redis key-value store on steroids Monday, September 13, 2010
- 66. O melhor dosdois mundos Monday, September 13, 2010
- 67. Dados bem guardados com SQL e com NoSQL Monday, September 13, 2010
- 68. Pesquisa direta no “banco de dados” 20tx/s Monday, September 13, 2010
- 69. Pesquisa passando pelo Redis: 200 tx/s Monday, September 13, 2010
- 70. Seus problemas acabaram! Monday,September 13, 2010
- 71.