is-BetStrike
plataforma fictícia de apostas desportivas
código fonte: https://github.com/joaoesteves10/IS-BetStrike
Contexto
Plataforma fictícia de apostas desportivas feita para a UC de Integração de Sistemas: simula o ecossistema de uma casa de apostas portuguesa que partia de três problemas estruturais: resultados de jogos inseridos manualmente, sistemas de apostas e pagamentos sem comunicação automática, e resolução de apostas com 15 a 30 minutos de atraso. A 1ª fase resolveu isto com integração REST entre os sistemas e toda a lógica de negócio centralizada em Stored Procedures SQL Server; a 2ª fase introduziu Kafka e RabbitMQ para desacoplar os serviços e reduzir latências, complementada por um microserviço de analytics em tempo real. É composta por 5 microserviços .NET independentes (gerador de dados, resultados, apostas, pagamentos e analytics) e um frontend em Angular, tudo orquestrado com Docker Compose.
Desafios técnicos
- retry sem perder mensagens — o RabbitMQ não deixa alterar headers de uma mensagem existente, por isso cada retry publica uma nova mensagem com um header x-retry-count incrementado; ao fim de 3 falhas, vai para a dead letter queue
- backpressure com prefetchCount — o worker só aceita a mensagem seguinte depois de confirmar a atual, evitando acumular trabalho em memória se o processamento abrandar
- comunicação entre microserviços — resultados, apostas e pagamentos como serviços independentes, cada um com a sua própria base de dados
- integração sem partilhar base de dados — a base de dados da FPF (resultados) e a da BetStrike (apostas) pertencem a organizações diferentes e nunca são acedidas diretamente uma pela outra; a sincronização é sempre feita por integração (polling HTTP na 1ª fase, consumo de stream Kafka na 2ª)
- lógica de negócio em stored procedures — todo o acesso à base de dados passa por Stored Procedures SQL Server, que correm em transações atómicas, evitando bypass da validação por outro cliente e eliminando race conditions, como dois utilizadores a apostar em simultâneo com o mesmo saldo insuficiente
- eventos em tempo real — o AnalyticsService consome eventos via Kafka para gerar alertas e estatísticas
- arranque reprodutível — toda a stack (bases de dados, filas, serviços e frontend) sobe com um único docker compose up
- testado sob carga — scripts de stress próprios chegaram às 30 000 apostas a ~260/segundo sem falhas; a limitação identificada foi a stored procedure de inserção de apostas, que mantém atomicidade (saldo, estado do jogo, inserção) por ser um requisito funcional, não um detalhe de performance a sacrificar
Screenshots
