Vitor Schiavo

Problem

Standard TLS only authenticates server to client. Required mutual authentication where both client and server verify identity using certificates, critical for API security and ISO 27001 compliance.

Solution

• Set up Cloudflare for Mutual TLS; both sides now present certificates, not just the server
• Generated and distributed client certificates to each authorized service
• Added certificate revocation and rotation so compromised certs can be killed immediately
• Certificate validation adds an identity control alongside network restrictions
• Automated the certificate lifecycle so rotation doesn't require manual steps

Problem

Needed secure, reliable communication between AWS and GCP for hybrid workloads. Public internet routing unacceptable for sensitive data. Required redundancy for high availability.

Solution

• Built HA VPN between AWS and GCP with redundant tunnels on both sides
• Configured BGP so failover is automatic, with no manual intervention when a tunnel drops
• Assigned private IPs and set up internal routing tables so traffic uses private addressing over encrypted VPN tunnels
• Traffic inside the VPN tunnels is encrypted with IPSec
• Added monitoring and alerts for tunnel health so issues are caught before they affect workloads

Problem

Traditional blue-green deployments require a 100% traffic switch, which is risky. Off-the-shelf tools didn't fit our multi-environment Kubernetes setup. Needed gradual rollout with automatic metric-based rollback.

Solution

• Wrote custom canary deployment automation from scratch; off-the-shelf tools didn't fit the multi-environment setup
• Progressive traffic split: 10% → 25% → 50% → 100%, with a gate at each stage
• Health checks run at each stage before traffic advances
• Automatic rollback kicks in when error rate or latency crosses defined thresholds
• Wired into Jenkins pipelines, works the same way for every team

Problem

Databases exposed with public IPs, unencrypted connections, password-only authentication. Non-compliant with ISO 27001. Vulnerable to network sniffing and unauthorized access.

Problem

160+ applications with direct nginx ingress and no centralized API management, rate limiting, or authentication layer. Difficult to enforce policies or monitor API usage consistently.

Problem

Deployments across four GKE clusters (dev · stg · prd · sdx) were manual, inconsistent, and error-prone. No single source of truth for cluster state, no audit trail, and high risk of configuration drift between environments. Teams needed kubectl access to deploy with no self-service model in place.

Solution — 9-Phase Implementation

• Phase 0: Installed ArgoCD on GKE PRD cluster via Helm with production-grade values
• Phase 1: Defined GitOps repository structure: apps/environments/charts hierarchy with Helm chart templates and per-env value overrides
• Phase 2: Configured ArgoCD Applications and AppProjects with RBAC boundaries per team and namespace
• Phase 3: Multi-cluster registration; all four GKE clusters (dev · stg · prd · sdx) as ArgoCD targets with cluster credentials stored in Secrets
• Phase 4: CI/CD pipeline integration via GitHub Actions image updater for automatic image tag propagation, branch promotion dev → stg → prd
• Phase 5: SSO/OIDC with Google Workspace + RBAC policies per team
• Phase 6: Prometheus metrics + Grafana dashboards for GitOps observability
• Phase 7: Incremental migration of existing workloads; audited all namespaces, converted to Helm charts, enabled self-heal and prune on non-prod
• Phase 8: Progressive delivery with Argo Rollouts, canary deployments with traffic splitting and automated rollback

Problem

GKE clusters and the underlying network infrastructure were provisioned manually with no IaC. No consistent multi-environment strategy, no prevent-destroy protection on critical network resources, and Terraform configuration was monolithic and impossible to reuse across environments.

Solution — 8-Phase Delivery

• Phase 1 — Architecture Design: Defined Shared VPC topology, subnet strategy, and GKE cluster requirements for 4 environments
• Phase 2 — GCP Project Setup: Created projects, enabled APIs, and configured IAM service accounts with least-privilege bindings
• Phase 3 — Network Infrastructure: Deployed Shared VPC host project, subnets, Cloud NAT, and firewall rules via Terraform
• Phase 4 — Modular Terraform: Refactored from monolithic inline resources to reusable modules; converted root config to module calls with environment-specific variable files
• Phase 5 — CI/CD Automation: GitHub Actions workflows for terraform plan on PR and terraform apply on merge; separate workflows per environment
• Phase 6 — GKE Cluster Deployment: Deployed all four GKE clusters (dev · stg · prd · sdx) using the automated pipelines
• Phase 7 — Safety Guardrails: Added prevent_destroy = true lifecycle blocks on VPC, subnets, and Cloud NAT to protect against accidental terraform destroy
• Phase 8 — Documentation: Architecture diagrams, operational runbooks, and module documentation for knowledge transfer

The threat

A compromised dependency can smuggle a cryptominer (such as xmrig) into a build and past code review, then quietly burn CPU on a production node with no application symptoms. The malicious code never appears in a diff, because it rides in on a transitive package and is assembled into the bundle at build time.

Detection & defense in depth

• Detect at the node: node-level CPU anomaly alerts (short threshold window) are the tripwire when the application itself looks healthy
• Contain fast: cordon the affected node, drain and reschedule onto clean nodes, then remediate the source and pin transitive versions
• Gate the pipeline: npm audit --audit-level=high plus Trivy image scanning on every pre-deploy build
• Enforce lockfiles: committed lockfiles required; CI fails if missing or changed without review
• Restrict the runtime: Pod Security Standards (restricted) across namespaces to block privilege escalation
• Default-deny egress: network policies block outbound to mining pools and unknown endpoints, so an intrusion is a dead end

Incident A — Third-Party CMS Loader [P1]: HTTP 500 across two regional markets

• Impact: 100% of page loads returning HTTP 500 from 13:08 UTC; full production outage across two regional markets
• Root cause: Third-party CMS API dependency had an outage; all pages failed server-side rendering
• Response: Identified dependency failure, implemented emergency static fallback, and escalated to vendor support
• Resolution: Service restored; added circuit-breaker pattern and health monitoring for external CMS dependencies

Incident B — Partner API [P2]: Credential Rotation Causing Auth Failure

• Impact: All partner authentication calls returning 401 from ~14:30 UTC after partner-side password rotation
• Root cause: Partner rotated credentials without coordinated notification; old password revoked mid-day
• Response: Diagnosed authentication failure from logs, obtained new credentials, updated GCP Secret Manager, triggered rolling restart
• Hardening: Established credential rotation runbook and pre-agreed notification SLA with partner

Problem

• 2 legacy Elastic Stack clusters: Elasticsearch 5 on EC2 and Elasticsearch 6 on ECS, both via docker-compose
• No role separation: every node handled master election, data storage, and ingest simultaneously
• Manual scaling, no self-healing, single points of failure
• Storage bottleneck: no S3 snapshots, no automated retention policies

Solution

• Consolidated both clusters into 1 unified EKS cluster on Elasticsearch 7.8
• Designed multi-node architecture with dedicated roles: 3 master (8 GB), 3 data (16 GB, 50 TB), 3 ingest (16 GB)
• Custom ECR image with S3 snapshot plugin for automated backup and retention
• Deployed via Helm Charts with rolling updates, PDB (maxUnavailable: 1), and soft anti-affinity
• Built 9 specialized Logstash pipelines for different log sources (GELF, K8s, NiFi, PHP, portal, services, reports)
• Filebeat DaemonSet with Kubernetes metadata enrichment for container log collection
• Fluent Bit as lightweight alternative collector with kernel-level filtering
• Kibana 3 replicas with CSV reporting (1 GB max), APM Server for tracing, Metricbeat for cluster health

Problem

• Business intelligence team had no real-time access to API and service event data
• Log data was siloed in Elasticsearch, not accessible for downstream analytics
• Multiple event sources (GELF, RabbitMQ, HTTP) needed unified routing to Kafka topics
• No standardized pipeline for streaming filtered events to analytics systems

Solution

• Designed dual-output Logstash pipelines: events indexed in Elasticsearch AND forwarded to Kafka topics
• Integrated with AWS MSK (Managed Streaming for Apache Kafka) with gzip compression
• Built conditional routing: API events filtered by service name and forwarded to dedicated Kafka topics for BI consumption
• RabbitMQ input plugin for message queue events alongside GELF and pipeline-to-pipeline routing
• Kafka producer configured with client_id tracking and topic-per-domain strategy

Solution

• Dec 2024: Enabled Claude AI for entire team
• Aug 2024: Onboarded QA and dev teams to GitHub Copilot
• Aug 2025: Evaluated Claude Code for automated PR reviews in Bitbucket pipelines
• Created best practices guides for AI-assisted development

What it does

A subscription service for Pokémon GO players to have their trainer codes automatically submitted to community listing sites daily. Users pick a plan, pay, and their code gets submitted every day without any manual action.

How it's built

• Full-stack Next.js 16 App Router with Server Components, Server Actions, and Docker multi-stage build deployed to Cloud Run (scale to zero)
• Dual payment gateway: Mercado Pago for PT/BRL subscribers, Stripe for EN+ES/USD; same codebase, locale-driven routing via middleware
• i18n with /pt, /en, /es subpaths; Accept-Language middleware auto-redirects on first visit
• Webhook state machine with idempotent processing and submission_logs table tracking every payment event
• Zero static credentials: GCP Secret Manager at runtime, Workload Identity Federation for GitHub → GCP auth in CI
• Admin panel (server-side HMAC-SHA256 sessions) for subscription management and webhook inspection
• Email confirmations via Resend with React Email templates · Database migrations via Drizzle ORM

What it does

The automation backend for the subscription service. A scheduled Cloud Run Job that reads active trainer codes from Cloud SQL and submits them to two community sites daily at 15:00 BRT, fully headless with no manual intervention.

How it's built

• Two independent scrapers: Puppeteer + stealth plugin for pokemongofriendcodes.com, Playwright for pogocodes.com (React-based form)
• React controlled component workaround on pogocodes.com; dispatches input events with bubbles: true to trigger synthetic event handlers
• Verification step after each submission: navigates to the listings page to confirm the code actually appears
• Batch processing (3 codes simultaneously) with configurable delays per action type to avoid rate limiting
• Database-driven: codes sourced from Cloud SQL trainer_codes table (single source of truth, synced from payment webhooks)
• Complete Terraform IaC for Cloud SQL, Cloud Run Jobs, Cloud Scheduler, Secret Manager, and IAM

What it does

A fully-featured Android app for organizing Secret Santa draws. Supports multiple groups, exclusion rules, wish lists, secure reveal, and sharing results via WhatsApp, Telegram, SMS, or Email. Available on Google Play.

How it's built

• Fully migrated to Kotlin (from Java) with MVVM architecture: AndroidViewModel + LiveData + Repository pattern
• Hilt for dependency injection · Coroutines for async database operations on IO thread
• Room ORM with dual-layer database (Room + legacy DAOs coexist; eager Room initialization ensures migrations complete first)
• Backtracking draw algorithm extracted to pure function (SorteioEngine.kt): testable, no side effects, handles impossible constraint scenarios gracefully
• Batch queries with INNER JOIN to eliminate N+1 problem on wish list counts · All DB writes in atomic transactions
• Edge-to-Edge layout (Android 15), PDF export (PDFKit), QR code generation, local notifications, backup/restore as JSON
• GitHub Actions CI/CD: push to master → internal Play track; tag v3.x → production track

What it does

The iOS counterpart to AmigoSecreto, same product concept rebuilt natively in Swift and SwiftUI for iPhone. Multiple groups, exclusion rules, wish lists, secure reveal, QR codes, PDF export, and local notifications. Zero external dependencies.

How it's built

• SwiftUI + SwiftData only, no third-party packages; persistence, UI, PDF, QR codes, and notifications all via native Apple frameworks
• MVVM via SwiftData's @Query and @Environment(\.modelContext) with no separate ViewModel classes needed
• JSON serialization workaround for many-to-many relationships (SwiftData limitation): exclusions and draw pairs stored as Data fields with computed property decoders
• Backtracking draw algorithm with 200-attempt limit; same logic as Android, adapted for Swift
• SequentialShareView: workaround for iOS limitation that prevents opening multiple URL schemes simultaneously; shows sequential buttons for WhatsApp, SMS, Email
• 6-page onboarding, draw history, statistics, backup/restore with JSON forward compatibility