gosigapp

Brazilian betting operators must send six categories of operational data to the Ministry of Finance's SIGAP platform on defined daily and monthly schedules. I treated that obligation as a systems problem: every run had to turn changing source data into a filing that was structurally valid, traceable, and ready within the reporting window.

The inputs arrived through S3 as ZIP archives covering bettors, wallets, sports betting, online games, and daily and monthly operator aggregates. Before SIGAP could accept them, the pipeline had to extract and validate XML, apply an RSA-SHA256 signature from a PKCS#12 certificate, compress and encode the result, authenticate with OAuth2, and transmit it over mutual TLS.

I built one Go processing core for the full path from S3 retrieval to SIGAP response handling. A batch CLI runs scheduled workloads, while an HTTP service exposes job control and progress for operational use. Around that core, dedicated commands inspect compliance, query submission status, backfill missing dates, and keep execution history in DynamoDB.

I moved preventable failures ahead of the network boundary. The pipeline validates XML against the six SIGAP schemas, and a dedicated compliance command checks schema conformance, certificate integrity, and configuration before packaging. The service layer also integrates with SIGAP's official Impedidos v2 service for self-exclusion and restriction checks.

Signing and transport are part of the submission contract, not optional hardening. The pipeline parses PKCS#12 certificates, applies RSA-SHA256 XML signatures, and sends the packaged payload through an mTLS client with cached OAuth2 tokens. Certificate material and API credentials stay outside the source code and enter through environment-based configuration.

I made retry behavior selective: network and 5xx failures receive bounded backoff, while 4xx responses return immediately for correction. Jobs move through queued, running, completed, failed, and cancelled states; structured execution records are written to DynamoDB. For recovery, the backfill tooling checks SIGAP for existing submissions before processing missing dates and treats duplicate-batch responses as already submitted rather than silently resending.

As the sole human developer, I translated the reporting requirements into the architecture, implemented the Go pipeline and operational tooling, connected AWS storage and audit services, and delivered the container and CI/CD path to ECS/Fargate. AI assisted implementation, but the system design, tradeoffs, verification, and deployment decisions remained my responsibility.

The system was deployed via AWS ECS/Fargate, and this case study is grounded in the private codebase, Docker image, GitHub Actions workflow, task definition, and sanitized fixture captures. It has no public graphic interface, and I do not publish operational volumes, uptime, rejection rates, or business impact that I cannot independently verify.

The repository remains private because it implements a regulated integration for an unnamed Brazilian betting operator. The diagrams and terminal captures use fixture configuration only. I can discuss the architecture, failure handling, security boundaries, and my engineering decisions in more depth without exposing the operator, its infrastructure, or its data.