Thiago
Fidelis
Frontend
Engineer

The Problem

The product team needed a reliable way to understand user behavior in production after each deploy — bug reports were vague and reproduction steps were hard to gather. The challenge was building a session capture system that could work at the scale of Mercado Livre without degrading performance for end users or creating compliance risk.

Architecture

Key Engineering Decisions

Performance-aware capture: Capturing events needed to be invisible to the user. The solution used throttling and idle-time scheduling to avoid competing with the main thread during critical user interactions.

Storybook-driven components: Every UI element of the replay interface was developed and documented in Storybook, enabling design review and QA without requiring live sessions.

Monitoring integration: The module was wired into New Relic, Kibana, Grafana, and Datadog from the start — making capture health and failure rates visible to the team in real time.

Trade-offs & Lessons

The hardest trade-off was between capture completeness and performance impact. Every additional event type captured had a cost. We prioritized high-signal interactions (errors, rage clicks, key flows) over exhaustive recording — keeping the module lean and the user experience unaffected.

The Problem

Multiple product teams were building UI independently, leading to visual inconsistency and duplicated effort. There was no single source of truth for how the product should look or behave, and design reviews were spending time correcting drift instead of evaluating new work.

Approach

Design tokens first: Before writing any component code, alignment happened on a token layer — spacing, color, typography, border-radius — all versioned and exported from a single source, keeping the library in sync with design.

Storybook as the contract: Every component was built in isolation in Storybook with documented props, usage guidelines, and accessibility notes. Storybook became the shared review surface for design and engineering.

ESLint and TypeScript as guardrails: Strong typing and linting rules enforced API consistency across components, catching misuse at development time rather than in production.

Trade-offs & Lessons

The main tension was between flexibility and consistency. Too rigid and teams work around the library; too loose and it stops being a system. The solution was well-typed props with sensible defaults and clear documentation on extension points — giving teams guardrails without walls.

The Context

At both Mercado Livre and Invillia, I worked within large-scale frontend ecosystems where multiple teams needed to ship independently. Micro frontends were the architectural pattern that enabled this — each team owning their slice of the product with its own deploy pipeline and development cadence.

Architecture

Key Engineering Concerns

Shared dependencies: React must be shared as a singleton or hooks break across remote boundaries. Managing shared versions carefully was critical to stability.

Modularity without isolation silos: Teams needed independence without losing visibility into each other's contracts. Clear interface definitions and monitoring across remotes kept integration healthy.

Observability across boundaries: Distributed architecture means distributed failure modes. Integration with New Relic and Splunk gave visibility into which remote was contributing to a user-facing issue.

Trade-offs & Lessons

Micro frontends optimize for team autonomy at the cost of additional infrastructure complexity. The right choice depends on team size and product scope — in large organizations like Mercado Livre, the autonomy gains far outweigh the coordination overhead of managing shared contracts.