Back to about

ACT Digital2026 — Present

Platform engineering for national beverage ecommerce at ACT Digital

Full Stack Developer | Ecommerce · Platform Team

Published on 6 min read

  • Platform Engineering
  • NestJS
  • AWS
  • React Native
  • SAP

At ACT Digital, I work on the Platform Engineering team allocated to Grupo Petrópolis — one of Brazil's largest beverage companies. The commercial surface that most people feel day to day is Bom Parceiro: a React Native ecommerce application with more than 40,000 active users and annual recurrence above R$1 billion.

This case study covers the shape of that role: what platform work looks like at commercial scale, how we keep services, mobile, and enterprise integrations coherent, and the engineering practices that turn infrastructure into leverage for product teams.

The role

I joined as a Full Stack Developer on the ecommerce Platform Team. The brief is not to own a single feature forever. It is to build and evolve the shared infrastructure, cloud services, and engineering capabilities that the company's commercial ecosystem depends on — so product teams can ship reliably without reinventing the same foundations.

Day-to-day ownership spans:

  • Backend services and platform APIs in Node.js, NestJS, and TypeScript
  • Cloud solutions on AWS that need to stay scalable and operable
  • CI/CD pipelines, deployment workflows, and delivery standards
  • Enterprise integrations — especially SAP — for commercial and order data
  • Performance work across APIs and the Bom Parceiro mobile client
  • Code reviews, automated testing, and documentation that keep the bar consistent

The problem space

Commercial ecommerce at this scale fails in operational ways before it fails in spectacular ones. An order path that waits on every enterprise hop feels broken even when every service is "up." A mobile screen that loads slowly loses trust with partners who live inside the app all day. A SAP sync that drifts silently creates support tickets that look like product bugs.

Grupo Petrópolis needed platform capabilities that held under real commercial pressure:

  • Mission-critical APIs used by tens of thousands of active users
  • Reliable synchronization of commercial, customer, and order data with SAP
  • Mobile experiences on Bom Parceiro that stayed snappy on imperfect networks
  • Checkout and payment flows where seconds of latency translate into abandoned sales
  • Delivery pipelines that multiple engineering teams could trust
  • Observability and standards so incidents were diagnosable, not tribal knowledge

That combination pushes platform work toward microservices boundaries, event-driven integration where sync would be dishonest, and AWS-backed operations — not a single monolith answering every commercial request inline.

What I built

Platform APIs and microservices

I build and maintain backend services and platform APIs using Node.js, NestJS, and TypeScript, with PostgreSQL as a core data store. These services support mission-critical commercial applications: clear contracts for mobile and internal consumers, predictable error behavior, and service boundaries that let teams evolve domains without coupling every release together.

Where the domain justified it, we applied microservices thinking — separate ownership of commercial flows, integrations, and shared platform concerns — instead of growing one service until every change became a coordination tax.

AWS cloud infrastructure

I develop and operate cloud-based solutions on AWS, including footprints with Lambda, API Gateway, S3, and CloudWatch. The goal is practical: improve scalability and resilience without making the platform harder to run. Containers with Docker keep local and pipeline environments honest about what ships to cloud.

CI/CD and engineering process

I design, automate, and improve CI/CD pipelines, deployment workflows, and engineering processes. Platform value compounds when shipping is boring: fewer manual steps, clearer failure signals, and delivery paths that product teams can reuse instead of inventing per-squad rituals.

SAP integrations

I design and maintain integrations with SAP, ensuring reliable synchronization of commercial and order data across distributed systems. We lean on event-driven architectures where synchronous request/response would force mobile or API callers to wait on enterprise hops they cannot control. The hard part is rarely "call the API." It is retries, partial failures, idempotency, and keeping commercial truth coherent when systems disagree for a moment.

Performance across backend and mobile

I improve application performance by finding bottlenecks across backend services and the React Native Bom Parceiro client. That work cut API response times by 72% and screen load times by 31%. On the checkout path, we adjusted the payment flow from 13 seconds to 9 seconds, improving the sales experience where latency is felt most directly.

Standards that reduce production pain

Through code reviews, automated testing, documentation, and shared development practices, we contributed to an 18% reduction in production bug reports. Platform engineering is partly culture: the same conventions that make reviews faster also make incidents rarer.

Architecture sketch

At a high level, the commercial platform looks like this:

Text
Bom Parceiro (React Native)


   API Gateway / platform APIs (NestJS)

        ├──► Commercial microservices ──► PostgreSQL

        ├──► Payment / checkout path

        └──► Event-driven sync


              SAP & enterprise systems


         AWS (Lambda, S3, CloudWatch) + CI/CD

Not every feature needs every box. The point is having honest boundaries: interactive mobile requests stay fast, enterprise sync happens where it belongs, and operators can see what failed when something drifts.

Engineering practices that mattered

A few habits paid for themselves repeatedly:

  • Instrument before you optimize — CloudWatch and service-level metrics made latency and failure modes visible before partners filed tickets.
  • Keep mobile contracts stable — Bom Parceiro depends on boring, predictable APIs; quiet contract breaks are worse than loud ones.
  • Treat SAP sync as a reliability problem — retries, idempotency, and event-driven handoffs beat hoping the enterprise system answers in time for a spinner.
  • Automate delivery — CI/CD and shared workflows reduce the tax every team pays to ship safely.
  • Measure the paths that sell — payment and screen-load latency are product outcomes, not vanity backend metrics.

Outcomes

This engagement is platform work with commercial consequences: faster APIs, quicker mobile screens, a shorter payment path, and fewer production bugs — while keeping AWS, SAP, and delivery standards coherent for the teams that build on top.

Concrete results from the work above:

  • 72% reduction in API response times
  • 31% reduction in screen load times
  • Payment flow improved from 13s to 9s
  • 18% fewer production bug reports
  • Shared NestJS/TypeScript services, AWS operations, and SAP integrations that product teams can reuse

Stack

LayerTools
MobileReact Native (Bom Parceiro)
BackendTypeScript, Node.js, NestJS, Java
DataPostgreSQL
Cloud & opsAWS (Lambda, API Gateway, S3, CloudWatch), Docker, CI/CD
IntegrationsSAP, event-driven sync
DisciplinePlatform engineering, microservices, code review, automated testing

Closing

ACT Digital put me inside a Platform Engineering team that has to make commercial software feel reliable at national scale. The work sits under Bom Parceiro and the broader Grupo Petrópolis ecosystem: APIs, cloud, integrations, delivery, and the performance discipline that turns platform investment into partner-facing speed. If you are hiring for platform or ecommerce engineering with similar constraints, this is the kind of ownership I bring.