How Víssimo Consolidated an iPaaS and AWS Lambdas onto One Orchestration Platform
Víssimo Group runs two premium wine brands in Brazil, Evino and Grand Cru, on a shared integration and data backbone spanning e-commerce platforms, ERPs, and BI. That backbone had grown organically: an iPaaS for commerce integrations, AWS Lambdas for BI pipelines, and scattered scripts filling the gaps. Under peak load it showed its limits. A 2024 FinOps review confirmed the structural problem. Víssimo consolidated both tool layers onto Kestra, cutting BI costs by 40%, reducing integration spend to roughly 10% of previous iPaaS levels, and running its first zero-incident Black Friday.
40%
BI and ETL cost reduction
90%
integration cost reduction
0 incidents
Black Friday
~600
workflows in production
"With Kestra, orchestration stopped being a fragile point in the architecture and became a stable foundation for the business."
The problem
01
No end-to-end traceability: failures only surfaced on the business dashboard
Víssimo's integration landscape had grown to cover two brands, two ERPs, and multiple commerce systems. Logs were spread across Datadog, CloudWatch, the ERP, BI systems, and Slack. When something failed, recovery meant hunting across five tools to find where in the chain it broke. Silent failures (order flows that dropped without raising an alert) only became visible when the business dashboard showed a gap. Knowledge of how integrations actually worked lived in two or three engineers' heads, not in any system.
02
Resilience improvised in code, not expressed as policy
Retry logic, timeout behavior, and reprocessing mechanisms were written by hand into each integration by whoever built it. An iPaaS gave connectors but no governance. AWS Lambdas gave execution but no state. Every failure scenario was something an engineer had coded, which also meant something an engineer had to understand, debug, and maintain. "Many nights were spent analyzing stuck order queues or reprocessing large volumes of data due to failures." There was no way to read a workflow definition and understand what its failure policy was.
03
A FinOps audit exposed two tools growing faster in cost than in value
In 2024, Víssimo launched a FinOps initiative to scale sustainably. The audit surfaced two structural line items. First: AWS Lambda-based BI pipelines, expensive and hard to govern as data complexity grew. Second: Digibee, the iPaaS running e-commerce integrations, where licensing costs were growing faster than the value delivered. Both pointed to the same root cause: the tools weren't orchestration. They were execution. Governance was improvised everywhere else. "Cost optimization was the trigger. Architecture was the gain."
// The requirement
A platform where resilience is declared, not improvised, and where retries, timeouts, and concurrency limits are visible in the workflow definition, not buried in application code.
What Kestra fixed
✓
Declarative resilience: retries and timeouts in the workflow, not in the code
Every Kestra workflow is a YAML file with explicit failure policy: triggers, concurrency limits, retry strategies, timeouts, and idempotency keys. The order-to-ERP pipeline caps at 50 concurrent executions (protecting SAP from burst), retries with exponential backoff up to five attempts, and anchors every execution to an order_id label for idempotent reprocessing. Retry logic stopped being an engineering decision and became an operational contract that anyone on the team can read. "Clicking doesn't scale. Versioned YAML does. Workflow is code. Code has PR, review, rollback, blame."
✓
End-to-end observability: every execution has a trace
When a flow fails, engineers can see exactly when the event fired, where the timeout occurred, and when the retry resolved it, all in a single view without switching between Datadog, CloudWatch, and the ERP. Mean time to resolution dropped. Knowledge that had lived in individual engineers' heads moved into the orchestrator, where anyone on the team can read it.
✓
Idempotency by design: reprocessing without fear of duplicates
Every workflow is anchored to a business key — an order_id, an inventory_update_id, a payment_id. Replaying a failed batch is routine, not an emergency. There's no risk of duplicate orders or double-processed inventory updates because the idempotency contract is declared in the workflow definition, not handled case-by-case in application code.
✓
One platform consolidating two tool layers at once
The evaluation covered five alternatives: n8n, Temporal, Prefect, Airflow, and Kestra. Víssimo's criteria reflected what the existing stack lacked: open source, declarative YAML, native state and replay, native observability, and a mental model that mapped to e-commerce workflows. Kestra was the only tool that met all five. Lambda-based BI pipelines were consolidated onto Kestra in Q2 2025. Digibee was decommissioned after the commerce integration migration in Q3 2025. Both cost lines collapsed at the same time. "It became clear that Kestra allowed us to consolidate responsibilities that were previously split across multiple tools — without increasing complexity." — Rafael Bartalotti, Engineering and Architecture Manager
Outcomes
90% integration cost reduction
Digibee's licensing model was expensive relative to what Kestra delivers at the infrastructure layer. After migration, integration costs dropped to roughly 10% of previous iPaaS spend.
40% BI and ETL cost reduction
Consolidating Lambda-based pipelines onto Kestra brought cost down while improving observability and performance. The same workloads now run with full execution tracing and declarative retry policies.
Zero catastrophic incidents on Black Friday 2025
"It was the most predictable and controlled Black Friday we've ever experienced." With ~600 workflows handling 70 to 100k executions per day and peak traffic concentrated in a single window, zero incidents represented a structural improvement, not a lucky night.
~600 workflows, 70–100k executions/day
The phased migration ran Q2 through Q3 2025: BI pipelines first, commerce integrations second. By late 2025, roughly 600 workflows were running in production on Kubernetes, covering the full Víssimo operation across both brands.
Kestra at Víssimo Group
Kestra OSS runs self-hosted on Kubernetes on AWS, with a JDBC backend (PostgreSQL). The deployment maintains a clear separation between the control plane (orchestration, state, retries, visibility) and workers (execution, scaling, isolation). Under heavy load and large-scale reprocessing, that separation is what held. The architecture is event-driven at its core: Kafka events and webhook triggers initiate workflows rather than polling schedules. Kafka absorbs volume; the workflow defines behavior.
The order-to-ERP pipeline illustrates the architecture. An order created in Magento fires a webhook event. Kestra picks it up, applies concurrency controls (capped at 50 concurrent executions to protect SAP from burst), pushes the order to SAP via HTTP, retries with exponential backoff on failure, and labels the execution with the order_id for idempotent replay. The full failure policy is in the YAML definition: no application code required to understand what happens when something breaks.
Rafael Bartalotti has moved into an AI innovation focus, and Víssimo is now prototyping Kestra as an orchestration layer for AI agents — starting with fraud detection. An agent that pulls recent orders, flags anomalies (five sequential orders with different credit cards from the same session), and routes alerts through a governed workflow with full audit trail. The architecture is the same as their e-commerce patterns: triggers, concurrency limits, idempotency, replay — applied to AI decision loops instead of ERP calls. "AI without orchestration is Russian roulette. An AI agent without replay and audit isn't automation. It's operational variability."
