Shopify

@antirez one data point on the discussion: Maaarcocr/liquid-fight-club the task: reimplement liquid from its specs shopify/liquid-spec the results: - rust seems to cost less overall - c is faster at runtime rust is also slightly more correct (less bad bugs)

Shopifyテーマ：snippetsについて 今回はShopifyテーマファイルにある、snippetsについての情報をまとめました。 sample-theme-file/ ├── assets/ ├── blocks/ ├── config/ ├── layout/ ├── locales/ ├── sections/ ├── snippets/ <--今回のトピック └── templates/ Snippetsの主な特徴 Shopifyテーマエディタ上では扱えない（sectionsなどにコードを直接埋め込む用途専用） テーマ全体で繰り返し使うコードに最適 Snippetsの使い方 Liquidコード内でsnippetを参照するには render タグを使う（snippetのファイル名を、.liquid 拡張子を省略して指定）。 //参照ファイル = snippet/product-card.liquid {% render 'product-card' for collection.products as product, show_price: true, size: 'large' %} render タグのパラメータ 一つの render タグ内で for や with は同時に指定できないが、for や with と一緒に変数を受け渡すことは可能。 【変数の受け渡し】 snippetの外部で作成された変数を渡すために使う。渡した変数への変更は、そのsnippet内でのみ反映される。 {% render 'product-card', product: product %} 【for】 配列内のすべての要素に対してsnippetをレンダリングするために使う。as パラメータ (任意) を指定 すると、snippet内でループ中の現在の要素を参照できる。さらに、ループ中のsnippet内では forloop オブジェクト（first、index、length など）にアクセスできる。 {% render 'filename' for array as item %} 【with】 単一のオブジェクトを渡すために使う（例: product オブジェクト、section オブジェクトなど)。追加で as を指定すると、snippet内でそのオブジェクトを参照する際のカスタム名を指定できる（as を指定しない場合、オブジェクトはsnippetのファイル名で参照できる）。 {% render 'filename' with object as name %} 補足：LiquidDoc (Shopify dev docs) を使ってドキュメントを追加できる。 {% doc %} Product card snippet @param {string} title - The title to display @param {number} [max_items] - Optional maximum number of items to show @example {% render 'example-snippet', title: 'Featured Products', max_items: 3 %} {% enddoc %} render タグのスコープ render タグを使用して出力されるsnippetは、独立した環境で動作し、グローバルオブジェクトと呼び出し時に明示的に渡された変数・オブジェクトのみを継承する。イメージ的にはプログラミングにおける「関数」に近く（実際の設計思想のもとにもなっている Shopify Liquid - PR#1122）、Online Store 2.0から include タグが非推奨となっている理由でもある。 render タグで利用できるものは以下の通り： グローバルオブジェクト（例: shop、settings、productテンプレート内のsnippetであれば product オブジェクトなど） パラメータとして明示的に渡された変数 注意：collectionテンプレート内で呼び出されたsnippetは collection オブジェクトを継承するが、product オブジェクトは継承しない。product オブジェクトが必要な場合は変数として渡す必要がある（例：{% render 'product-card', product: product %}）。 snippet内から特定の変数・オブジェクトが参照できているかを確認するには、その変数をコンソールへ出力する手がある。その際、json フィルターを使うと、存在しない変数は null、空文字列は "" として出力される（json フィルターなしだと、存在しない変数と空文字列はどちらも同じ出力で見分けがつかない）。 <script> //サンプルJavaScript const title = {{ collection.title | json }}; const product = {{ product | json }}; console.log('collection-title: ', title); console.log('Product-object: ', product); </script> include タグについて（非推奨・参考用） Snippetの挿入方法として、{% include %} タグも存在するが、2019年8月以降、{% render %} タグの使用が推奨されている。 includeタグの構文 {% include 'filename' %} 非推奨とされる理由は、include が呼び出し元（テンプレートファイル）と同じ変数スコープで実行されるため。具体的には: snippetは呼び出し元のあらゆる変数を読み書きできる。 snippet内で変更された変数や、新しく作られた変数は外部に漏れ出す。 これにより意図しない変数の変更が発生し、コードの可読性・保守性が低下するのに加えて、余分なメモリオーバーヘッドが生じパフォーマンスも低下する。 参考資料 Snippets - Shopify dev docs render - Shopify dev docs include - Shopify dev docs Add new {% render %} tag - Shopify GitHub

Fast-Forwarding Past the 9 A.M. Reminder, Bob Ross Paints Straight to the GPU, and a README That Confesses Its Own Bugs --- title: "Fast-Forwarding Past the 9 A.M. Reminder, Bob Ross Paints Straight to the GPU, and a README That Confesses Its Own Bugs" published: true cover_image: dev-to-uploads.s3.us-east-2.amazonaws.com description: "Explore Appduct from Callstack, which turns your running app into an MCP server for AI agents, and react-native-skia-webgpu-video for GPU video editing on Skia 3." tags: reactnative, javascript, mobile, expo canonical_url: thereactnativerewind.com --- You’re reading The React Native Rewind #63. --- Great Scott, Your App Has a Time Machine Doc Brown needed a DeLorean and 1.21 gigawatts to jump forward in time. Our QA agents just need to test a reminder that fires at 9 a.m., and right now they sit and wait for it like the rest of us. Szymon Chmal and Callstack launched Appduct on October 20 to fix exactly that. What does it actually do? Appduct turns your running app into an MCP server (the protocol agents use to call outside tools). You register functions like advance_time, seed_cart or set_feature_flag, and the agent calls them instead of tapping through six screens. The handlers run your app's own code, so a test starts on the screen it cares about rather than the login page. Call advance_time with 60 seconds, and the 9 a.m. reminder fires without anyone staring at a clock. import { useAppductTool } from "@appduct/react-native"; import { z } from "zod"; export function AppductTools() { useAppductTool({ name: "seed_cart", description: "Fill the cart with test items.", inputSchema: z.object({ items: z.number() }), handler: async ({ items }) => ({ added: items }), }); return null; } Mount that near the root, and any agent that speaks MCP can call it. The same tool works in Swift, Kotlin, Flutter and on the web. Release builds leave it out unless you opt in. How does the agent know the app is ready? Instead of sleep(3000) and a prayer, the app posts an event like checkout_completed, and the agent waits for it. The connection runs through a small daemon on your machine and an encrypted WebSocket, paired with a single-use link (or a QR code on a real device). For the taps that still need tapping, it pairs with Callstack's agent-device. Does it work in normal tests? A day later came @appduct/e2e, which wraps the e2e tests you already have. One call fills the cart, and the test runner's AI agent gets the same tools. The same test runs on web, iOS and Android. !Appduct e2e seed cart demo Where our tests are going, they don't need login screens. 👉 Appduct --- !Ancient Aliens ProGuard meme Happy Little Frames Bob Ross could turn a blank canvas into a mountain range in half an hour. React Native video editing usually takes longer, plus a native SDK and a lot of bridge code. Sebastien Hecart published the first beta of react-native-skia-webgpu-video on October 19. What is it? It plays, composes and exports video on top of React Native Skia 3 and William Candillon's React Native WebGPU (the GPU API that Skia 3 now draws through). Every video frame lands on a Skia canvas, so we can paint text, shapes and filters straight on top. Frames travel from the phone's decoder to the encoder on the GPU, without a detour through JavaScript. The trick is that one worklet (a small function that runs off the JS thread) draws both the live preview and the exported file. const drawFrame: FrameDrawer = (props) => { 'worklet'; const { canvas, frames, width, height } = props; const frame = frames.clip; if (frame) { drawVideoFrame(canvas, frame, { x: 0, y: 0, width, height }, { fit: 'contain' }); } // Draw your Skia text, shapes, or overlays here. }; await exportVideoComposition({ videoComposition: composition, drawFrame, outPath, width: 1280, height: 720, frameRate: 30, bitRate: 5_000_000, }); It picks up where the older Skia Video left off, rewritten from scratch for Skia 3. Is anyone using it yet? Giulio Amato has already moved his video editor off Media3 (Android's native media library) and onto it. Because the same code draws the preview and the export, what we see on the timeline is exactly what lands in the file. !Skia video editor demo What's the catch? It's a beta, tested on an iPhone 15 Pro and a Pixel 8a. HDR isn't qualified yet. It pins exact Skia and WebGPU versions and needs the New Architecture and a native rebuild. So Expo Go is out. The README lists its known bugs with refreshing honesty, which is more than most of our side projects manage. Beta 3 on October 22 already cut a 4K frame on iOS from 33 MB to 12 MB. There are no mistakes, just happy little dropped frames. 👉 react-native-skia-webgpu-video --- !Afraid to ask pod install meme 📦 Nitro V1 alpha Marc Rousavy (@mrousavy) has opened the doors on the first Nitro V1 alpha, so library authors can grab the alpha-nightly tag and start poking at the future. The same week, his fbjni PR made every call into Java and Kotlin 14% faster, which is a lot of speed for one merged pull request. 📦 Radon IDE 1.20 The iPhone Duo simulator now folds right inside your editor, and Radon warns you before you launch an app that iOS 27 is about to crash for skipping the UIScene lifecycle. 📝 Supporting iPhone Duo with Expo Apple's first foldable landed on Friday, and Expo's guide explains why insets.top is suddenly zero and your tab bar has moved into a rail on the side. 📦 React Native Windows 0.85 The legacy architecture has finally been shown the door, so it's New Architecture only from here, and you'll need Visual Studio 2026 to get in. 📦 React Native Firebase 27 CocoaPods is out and Swift Package Manager is in on iOS, and the ML package has been laid to rest now that Google has discontinued it. 📦 Unistyles 3.6 A new experimental Metro integration lets you ditch the Babel plugin, and plain views now re-render in half the time. 📦 Hot Updater 1.1 Over-the-air updates now reach brownfield apps too, and bumping your version number no longer locks you out of shipping a quick fix. 📦 React Native Bottom Tabs 1.5 Swift Package Manager support has arrived, along with a new prominent tab role for the one tab on iOS 27 that deserves to stand out from the crowd. 📦 create-react-native-library 0.64 Satyajit Sahoo (@satya164) has taken the C++ template out of experimental, so your next native module can be written in C++ without feeling like a science project. 📦 React Native Better PDF 1.1 Hand it three PDFs and it stitches them into one document with a single page count and search, which is exactly the trick react-native-pdf can't pull off. !Goodbye GIF --- Authored by Luke Farrell and edited by Fran Ríos. If you’re enjoying this newsletter, why not help us grow? Share it with your friends, family, and even that one coworker who always “forgets” to update dependencies. Use this link: thereactnativerewind.com.

Shopify CLI 5.0が出た 少し前に変わったSHOPIFY_APP_AUTOMATION_TOKENが非推奨になり、SHOPIFY_SERVICE_ACCOUNT_TOKENを使用するように変わってるから、CIまわりの設定が変わりそう github.com/Shopify/cli/releases/tag/5.0.0

@hunkybill Same topics, sure. That's the table of contents. The commands underneath changed: app logs removed, theme dev --poll gone, existing JSON output reshaped. Breaking changes means a new major version. That's semver working as we promised: github.com/Shopify/cli/releases/tag/5.0.0

Design Token Architecture for Scalable Theming - How I organize a token taxonomy that survives scale - Why Style Dictionary is table stakes — and how to extend it - Token versioning & publishing that won't break teams - Mapping tokens across web and native platforms without surprises - A migration checklist you can run this week Design tokens are the single source of truth that determines whether your product family remains consistent or fragments into one-off styles across teams and platforms . When teams treat tokens as an afterthought, theming becomes a long-running maintenance tax — you trade speed today for chaos tomorrow. The problem shows up as duplicated hex values in three repos, three different dark-mode strategies, components that look off by a pixel across platforms, and last-minute accessibility fixes that slip through. Teams waste time reconciling visual regressions; product launches stall while engineers hunt down where a color actually lives. That is a governance and tooling failure — not a design problem. How I organize a token taxonomy that survives scale Design tokens must do one job: make visual decisions explicit, discoverable, and changeable without touching component code. The pragmatic taxonomy I use separates tokens into three layers: raw tokens, aliases, and semantic tokens. That separation keeps intent clear and reduces blast radius when values change . - Raw tokens (primitives) — atomic values: hex/rgb colors, numeric spacing scales, font families, raw sizes. These change rarely and should map closely to source assets from designers. - Alias tokens (scales & palettes) — reusable scales and brand palette items (for example blue.500, space.3). Aliases centralize a single design decision (the scale) and let you repurpose it consistently. - Semantic tokens (contracts) — named for purpose, not color or size: color.button.primary.bg, radius.card.default, typography.heading.1. Components consume semantic tokens only. | Layer | Example name | Typical owner | Change frequency | Use by code | |---|---:|---|---:|---| | Raw (primitive) | color.raw.blue.500 | Design tokens team | Very low | Not directly by components | | Alias | color.alias.brand.primary | Design system team | Low | Used to compose semantic tokens | | Semantic | color.button.primary.bg | Component/product teams | Moderate | Directly consumed by components | Example token JSON (Style Dictionary / DTCG-friendly structure): { "color": { "raw": { "blue": { "500": { "value": "#0B5FFF", "type": "color", "description": "Brand blue 500 (sRGB)" } }, "white": { "value": "#FFFFFF", "type": "color" } }, "alias": { "brand": { "primary": { "value": "{color.raw.blue.500.value}" } } }, "semantic": { "button": { "primary": { "background": { "value": "{color.alias.brand.primary.value}" }, "text": { "value": "{color.raw.white.value}" } } } } } } Why this matters in practice: - Stability: Components reference semantic tokens only; you can retune an alias or raw value without changing component code. - Traceability: Each token carries description, type, and optional deprecated flags so maintainers and codemods can map change impact. - Theming: Build themes by swapping alias values (or semantic overrides) rather than editing component usage. Style Dictionary (and other tools) favor a CTI (category-type-item) layout to support transforms and filters. Use that shape to make automated transforms reliable and to enrich tokens with metadata for platform-specific builds . > Important: Treat semantic tokens as the contract between design and engineering — raw values are implementation detail, not the contract. Why Style Dictionary is table stakes — and how to extend it Style Dictionary is the pragmatic choice for multi-platform token pipelines because it already understands transforms, formats, and common platform needs (CSS, JS, Android, iOS) and is extensible with custom transforms and formats . Use it as the build engine, not the policy system. Typical config (excerpt): // style-dictionary.config.js module.exports = { source: ['tokens/**/*.json'], platforms: { css: { transformGroup: 'css', buildPath: 'dist/css/', files: [{ destination: 'variables.css', format: 'css/variables', options: { outputReferences: true } }] }, js: { transformGroup: 'js', buildPath: 'dist/js/', files: [{ destination: 'tokens.esm.js', format: 'javascript/esm' }] }, android: { transformGroup: 'android', buildPath: 'dist/android/', files: [{ destination: 'colors.xml', format: 'android/resources' }] }, ios: { transformGroup: 'ios', buildPath: 'dist/ios/', files: [{ destination: 'Colors.swift', format: 'ios-swift/class.swift' }] } } }; Why you will extend Style Dictionary: - Built-in transforms handle name casing and unit conversions, but you will need platform-specific tweaks: px -> dp/sp for Android, rem -> pt for iOS typography, and color-space conversions for Display P3 or platform-native color types . - Preserve token references in outputs using options.outputReferences so generated CSS/JS produces var(--semantic-token, var(--alias-token)) fallbacks and keeps intent readable downstream . Custom transform example (register a simple size transform): const StyleDictionary = require('style-dictionary'); StyleDictionary.registerTransform({ name: 'size/pxToDp', type: 'value', matcher: token => token.type === 'size', transformer: token => `${Math.round(parseFloat(token.value) * (160/96))}dp` }); Operational notes: - Run StyleDictionary.buildAllPlatforms() inside CI to emit a deterministic set of artifacts (CSS variables, TypeScript types, Android XML, iOS Swift files). - Keep transforms idempotent and testable. Add unit tests for a transform that converts spacing across platforms. Style Dictionary is not the only tool, but it is widely adopted and integrates with the newer DTCG (Design Tokens) movement to standardize JSON formats across tools . Token versioning & publishing that won't break teams Treat your token package like a public API. Use semantic versioning and map changes to semantic impact so downstream consumers can safely adopt updates . Semver mapping I use: | Change type | SemVer bump | Example | |---|---:|---| | Breaking semantics or removals | Major (1.x → 2.0.0) | Rename color.button.primary.bg to a different function | | Additive, non-breaking tokens or new themes | Minor (1.2.0) | Add color.toast.info.bg | | Fix metadata, typos, build fixes | Patch (1.2.1) | Correct description or type, rebuild artifacts | Operational policy: 1. Add a deprecated: true flag and replacement pointer to old tokens in a minor release. Consumers get lint warnings before removal. 2. Remove a deprecated token only in a major release; include a clear migration table in release notes. 3. Publish per-semver release artifacts for each platform and include exact SHA/tarball links for native consumers. Distribution patterns: - Publish a canonical design-tokens npm package with generated artifacts (dist/css, dist/js, dist/android, dist/ios). Shopify and others publish token packages to npm as a single distribution point . - For very large ecosystems, split tokens into smaller packages (per-component token packages). Fluent UI’s semantic-tokens RFC describes the per-component package approach to reduce the blast radius and to emit per-component fallback CSS variables . Automated release pipeline (example): - CI: npx style-dictionary build → run token validation linters → run color-contrast checks → build artifacts → npm version {patch|minor|major} → npm publish. - Add changelog entries that map old→new tokens and include example replacement code snippets. Atlassian’s token ecosystem shows how linting and codemods can be part of the rollout: they expose a token() helper, lint rules, and codemods to help replace raw values with tokens safely . Use those patterns to avoid surprise breakages. Mapping tokens across web and native platforms without surprises Cross-platform pitfalls are predictable: unit mismatches (px vs dp vs pt), color-space mismatches (sRGB vs Display P3), and different platform naming conventions. Plan transforms to handle those differences centrally rather than ad-hoc in product code . Key tactics: - Encode type and unit metadata on tokens so transforms can make deterministic conversions (for example type: "size", unit: "rem"). - Use Style Dictionary’s built-in transforms for common conversions (remToSp, remToDp) and color transforms for different platform color objects . - For color, prefer storing tokens in a modern color space and generate platform-specific representations in the build step. The DTCG spec now documents color handling and interoperable color formats; align your schema to be compatible . Example CSS-based theming pattern (generate with Style Dictionary): /* dist/css/variables.css (generated) */ :root { --color-button-primary-bg: #0B5FFF; --color-button-primary-text: #FFFFFF; } [data-theme="dark"] { --color-button-primary-bg: #093b9f; } Fallback strategy for gradual migration (generated): /* in component CSS */ background: var(--semantic-button-primary-bg, var(--alias-brand-primary, #0B5FFF)); For native: - Android: emit colors.xml under res/values/ with names converted to snake_case or lowercase as required. - iOS: emit Colors.swift or .xcassets + color catalogs, using PascalCase or idiomatic Swift names. Style Dictionary’s formats include a wide set of ready-made outputs for Android and iOS; use those and customize only when necessary . You can also generate TypeScript declarations to get strong typings for token consumption on the web . Design tool sync: - Keep designers and engineers aligned by syncing tokens from Figma (Tokens Studio / Figma Tokens plugin) into the token repository, then run the build pipeline to produce artifacts consumers use . A migration checklist you can run this week This is a compact, runnable checklist. Each line is a discrete sprint chunk. 1. Audit (1 week) - Extract current variables and hard-coded values across repos (grep/shell scripts, theme folders). - Export the design file tokens (Tokens Studio or Figma Tokens) to JSON for reference . 2. Define taxonomy & ownership (1 week) - Create folders: tokens/raw/, tokens/alias/, tokens/semantic/, tokens/themes/. - Author token naming conventions (CTI) and a small governance doc. 3. Seed tokens & config (1 week) - Put primitives under raw/; create alias scale files; define the initial semantic tokens. - Add style-dictionary.config.js and a package.json script: "build:tokens": "style-dictionary build". 4. Build & validate (ongoing) - CI job: npm run build:tokens → run a token linter and color-contrast checks (automate with an a11y script). - Commit generated artifacts to an artifacts branch or publish to an internal npm registry. 5. Pilot adoption (1 sprint) - Pick a single small component or page. Use the semantic tokens only in that module. - Add a temporary compatibility layer if needed: component reads semantic token then falls back to legacy CSS var. 6. Codemod and scale (2–4 sprints) - Replace direct hex values and legacy CSS vars progressively via codemods and lint rules. - Publish a minor release with deprecated flags before removal. 7. Ongoing governance - Enforce token usage with lint rules and CI checks. - Use change logs that include explicit migration paths and code snippets. Quick example package.json tokens scripts: { "scripts": { "build:tokens": "style-dictionary build", "test:tokens": "node ./scripts/validate-tokens.js", "release:tokens": "npm run build:tokens && standard-version" } } Short codemod pattern (conceptual) to replace var(--old-token) with semantic helper usage: // pseudo-code for jscodeshift replacement // find CSS-in-JS literal strings containing 'var(--old-token)' and replace with `token('color.button.primary.bg')` Real-world reference points: - Atlassian publishes token linting and codemods to help teams migrate and enforce usage . - Shopify historically published token artifacts for multiple formats and distributed via npm . - Fluent UI is moving toward per-component semantic token packages and explicit fallback structures to reduce breaking changes . > Callout: Ship early, pilot wide. A single component fully migrated to semantic tokens is worth more than half a token repo left in limbo. Adopt the taxonomy, automate builds with Style Dictionary, and treat tokens like a public API: version them, test them, and communicate changes. That approach turns theming from a constant firefight into a predictable engineering workflow and makes consistent cross-platform theming achievable at scale . Sources: Design Tokens Community Group - Specification and ecosystem guidance for the DTCG JSON format and community-driven best practices; used to justify token standardization and cross-tool interoperability. Style Dictionary — Built-in formats & transforms reference - Documentation of Style Dictionary formats, transform groups, and transform registration used for platform builds and customization examples. Using CSS custom properties (MDN) - Behavior, scoping, and @property guidance for CSS custom properties used in theming and fallback strategies. Semantic Versioning 2.0.0 (SemVer) - The semantic versioning specification referenced for mapping token changes to version bumps and release policy. Atlassian Design System — Use tokens in code - Concrete examples of token helper functions, linting guidance, and migration tooling recommendations used as a practical model for adoption. Shopify Polaris Tokens (GitHub) - Example of a real-world token package and distribution approach (npm, multiple formats) illustrating multi-format distribution. Tokens Studio for Figma (official repo) - The Figma plugin used by many teams to manage tokens in design files and sync them to code; referenced for design tooling integration. Fluent UI RFC: Fluent Semantic Tokens (GitHub issue) - A real-world RFC discussing per-component semantic tokens, fallback structures, and reduced blast radius for token changes.

Hey @ShopifyDevs the App Bridge API has stopped working for the camera scanner in iOS This is causing issues for Merchants trying to pack orders shopify-app-bridge#589

こちらのスキルに対するフィードバックも受け付けています！ community.shopify.dev CLIはオープンソースなので、直接PR送ることも可能です！ github.com/Shopify/cli/tree/main/packages/app/src…

How we create and optimize shops with Claude Code (Full Workflow + Tool Stack) Everyone knows how to use Claude chat. Here's how we use Claude Code to build real software, custom client apps and Shopify stores. Work with us to scale your brand:lotuxagency.com Follow along on Instagram: instagram.com Get my dev workflow + all plugins mentioned: - Dev Workflow: dropbox.com - VSCode: code.visualstudio.com - Github: github.com - Caveman: juliusbrussee/caveman - Claude Plugins: anthropics/claude-plugins-official - Impeccable: pbakaus/impeccable - Marketing Skills: coreyhaines31/marketingskills - Superpowers: obra/superpowers - Shopify AI Toolkit: Shopify/Shopify-AI-Toolkit - Context7: upstash/context7 Timestamps: 00:00 Intro 00:45 The custom app we built for a client 01:33 Principles first: code, GitHub & deployment 03:26 Branches, pull requests & merges explained 04:40 Previewing changes on localhost 05:24 Setting up VS Code + Claude Code 06:27 My master workflow document 07:28 The MCP servers to connect first 09:30 The plugins I recommend 10:53 Your context window: /compact & /clear 11:47 Impeccable, Superpowers, Shopify & Context7 13:01 Downloading your Shopify theme locally 14:47 The CLAUDE.md file 15:30 Plan mode vs auto mode 18:50 Connecting Shopify to GitHub 21:36 A store built with zero apps 22:38 Designing in Claude Design first 24:37 From design to code 25:04 Wrap-up

Resiliência por Experimentação: Aplicação do ChaosEngineeringMasterDeck na Validação de uma Arquitetura de Microsserviços em Nuvem Resumo. Sistemas distribuídos em nuvem estão sujeitos a falhas parciais que dificilmente são reproduzidas por testes funcionais convencionais. Neste artigo, apresento o Chaos Engineering como disciplina experimental voltada à verificação empírica da resiliência e descrevo o ChaosEngineeringMasterDeck, framework que minha equipe utiliza para estruturar experimentos de caos em cartas padronizadas, compostas por hipótese, variável injetada, métricas de controle, Blast Radius e condição de aborto. Como estudo de caso, relato a aplicação da carta REDE-07, que injeta latência na comunicação entre dois microsserviços Spring Boot executados no Amazon EKS. A primeira execução refutou nossa hipótese de resiliência e evidenciou o esgotamento do pool de threads causado pela ausência de limite de tempo nas chamadas remotas. Após adotarmos de forma combinada os padrões Time Limiter, Bulkhead, Circuit Breaker e Fallback, a segunda execução confirmou a hipótese. Concluo que a prática converte suposições sobre resiliência em evidências mensuráveis e fortalece a responsabilidade compartilhada característica da cultura DevOps. Palavras-chave: Chaos Engineering; resiliência; sistemas distribuídos; microsserviços; observabilidade; DevOps. --- 1. Introdução Atuo como engenheiro de software em uma equipe responsável por uma plataforma de comércio eletrônico baseada em microsserviços. Ao longo da migração dessa plataforma para a nuvem, percebi que a mesma arquitetura que nos trouxe escalabilidade e autonomia também aumentou de forma expressiva a complexidade operacional do sistema. Em uma arquitetura distribuída, cada chamada de rede representa um ponto potencial de falha, e a interação entre componentes produz comportamentos emergentes que não se manifestam em testes isolados. Falhas parciais, como degradação de latência, perda de uma zona de disponibilidade ou indisponibilidade temporária de um banco de dados, tendem a se propagar em cascata quando os mecanismos de proteção não foram adequadamente configurados. Foi nesse contexto que minha equipe passou a adotar o Chaos Engineering, definido como a disciplina de realizar experimentos sobre um sistema com o objetivo de construir confiança em sua capacidade de suportar condições turbulentas em produção (BASIRI et al., 2016). A prática foi sistematizada pela Netflix durante a migração de sua infraestrutura para a Amazon Web Services, quando a empresa desenvolveu o Chaos Monkey, ferramenta que encerra instâncias aleatoriamente em produção para forçar o projeto de serviços tolerantes à perda de nós (BASIRI et al., 2016). 1.1 Justificativa: por que provocar falhas intencionalmente O argumento que me convenceu a defender essa prática internamente é simples: falhas em sistemas distribuídos são inevitáveis. Quando aceito essa premissa, a pergunta relevante deixa de ser se o sistema falhará e passa a ser como ele se comportará quando falhar. Ao provocarmos falhas em condições controladas, com a equipe disponível, monitoramento ativo e plano de reversão definido, conseguimos descobrir fragilidades a um custo significativamente menor do que o de um incidente não planejado. Os testes automatizados que já mantínhamos verificam se o sistema produz o resultado esperado sob condições conhecidas. O Chaos Engineering, por sua vez, investiga o comportamento do sistema sob condições adversas realistas, frequentemente associadas a configurações de infraestrutura, volume de tráfego e interações entre serviços que existem apenas em produção. 1.2 Mudança de paradigma Adotar a prática exigiu de mim e da minha equipe uma mudança na forma de conceber a confiabilidade, que sintetizo no Quadro 1. Quadro 1 – Comparação entre a abordagem tradicional e a abordagem do Chaos Engineering | Dimensão | Abordagem tradicional | Abordagem do Chaos Engineering | |---|---|---| | Objetivo | Evitar a ocorrência de falhas | Garantir a continuidade do serviço apesar das falhas | | Fonte de confiança | Testes funcionais aprovados | Falhas reais suportadas sob observação | | Natureza dos incidentes | Eventos inesperados | Hipóteses previamente testadas | | Resiliência | Presumida a partir do projeto | Verificada empiricamente | Fonte: elaborado pelo autor. 1.3 Princípios fundamentais Para orientar nossos experimentos, adotei como referência os Princípios de Chaos Engineering (PRINCIPLES OF CHAOS ENGINEERING, 2019), que estabelecem cinco diretrizes: 1. Formular uma hipótese em torno do estado estável (steady state), definido por métricas observáveis de negócio e de sistema, e não pela simples disponibilidade dos servidores. 2. Variar eventos do mundo real, injetando falhas que efetivamente ocorrem em produção, como latência, perda de nós e esgotamento de recursos. 3. Executar experimentos em produção ou no ambiente que mais se aproxime dela. 4. Automatizar os experimentos para que sejam executados continuamente. 5. Minimizar o Blast Radius, isto é, limitar o escopo do impacto potencial e ampliá-lo apenas à medida que a confiança no sistema aumenta. Nas seções seguintes, descrevo como operacionalizamos esses princípios por meio do ChaosEngineeringMasterDeck e relato um estudo de caso de sua aplicação. --- 2. O ChaosEngineeringMasterDeck 2.1 Definição O ChaosEngineeringMasterDeck é o framework que minha equipe desenvolveu para padronizar e priorizar experimentos de caos. Cada experimento é representado por uma carta, que possui uma versão impressa, utilizada em sessões presenciais de simulação que chamamos de GameDays, e uma versão em arquivo YAML versionado no repositório do projeto. Essa dupla representação nos permite conduzir o mesmo experimento manualmente, para fins de aprendizado coletivo, ou de forma automatizada, como etapa recorrente do pipeline de entrega. Concebemos o framework para resolver três limitações que eu havia observado em nossa prática anterior: - Ausência de padronização: cada engenheiro descrevia experimentos de uma forma, o que impedia a comparação de resultados. - Ausência de salvaguardas: iniciávamos experimentos sem condições de interrupção previamente definidas. - Baixo engajamento: a prática era percebida pelo time como atividade adicional e desvinculada do desenvolvimento. O formato de baralho introduziu um componente de gamificação que, na minha experiência, favoreceu a participação conjunta das equipes de desenvolvimento e operações. 2.2 Organização por naipes e severidade Agrupamos as cartas em quatro naipes, cada um correspondente a uma camada da arquitetura, conforme o Quadro 2. Quadro 2 – Naipes do ChaosEngineeringMasterDeck | Naipe | Camada | Exemplos de experimentos | |---|---|---| | Rede | Comunicação entre serviços | Latência elevada, perda de pacotes, partição de rede, falha de resolução DNS | | Computação | Instâncias, contêineres e zonas | Encerramento de pods, saturação de CPU, perda de uma zona de disponibilidade | | Dados | Bancos de dados, cache e filas | Failover de banco de dados, indisponibilidade de cache, acúmulo de mensagens | | Dependências | Serviços internos e externos | Indisponibilidade de gateway de pagamento, API externa retornando HTTP 503 | Fonte: elaborado pelo autor. Cada carta possui ainda um nível de severidade de 1 a 5. Estabelecemos uma regra de progressão segundo a qual equipes iniciantes executam apenas cartas de níveis 1 e 2, e cartas de níveis 4 e 5, como a perda de uma região inteira, só são habilitadas após a execução bem-sucedida das cartas de menor severidade do mesmo naipe. Com essa regra, aplicamos o princípio de minimização do Blast Radius no nível do programa de experimentos, e não apenas no nível de cada experimento individual. 2.3 Estrutura de uma carta Estruturei as cartas de acordo com as etapas do método científico. A Figura 1 apresenta o modelo que utilizamos. Figura 1 – Modelo de carta do ChaosEngineeringMasterDeck +------------------------------------------------+ | [NAIPE]-[NÚMERO] Severidade: N | | Título do experimento | +------------------------------------------------+ | HIPÓTESE | | Se [falha], então [estado estável se mantém],| | porque [mecanismo de resiliência]. | | | | ESTADO ESTÁVEL métricas e valores-base | | VARIÁVEL INJETADA tipo, intensidade, tempo | | BLAST RADIUS limite máximo de impacto | | CONDIÇÃO DE ABORTO critérios de interrupção | | ROLLBACK procedimento de reversão | +------------------------------------------------+ Fonte: elaborado pelo autor. Os campos têm as seguintes funções: - Hipótese: deve ser formulada obrigatoriamente no padrão "Se [falha], então [o estado estável se mantém], porque [mecanismo de resiliência]". Insisti na exigência da cláusula causal porque ela impede que executemos experimentos nos quais não conseguimos identificar o mecanismo que deveria proteger o sistema, o que por si só já constitui um achado relevante. - Estado estável: conjunto de métricas que caracterizam o comportamento normal do sistema, com seus respectivos valores de referência. - Variável injetada: a variável independente do experimento, especificada por tipo, alvo, intensidade, proporção do tráfego afetado e duração. - Métricas de controle: as mesmas métricas do estado estável, que comparamos entre um grupo de controle, não submetido à falha, e um grupo experimental. - Blast Radius: delimitação do impacto máximo admissível em termos de ambiente, usuários, serviços e tempo. - Condição de aborto: limiares cuja violação interrompe o experimento automaticamente. --- 3. Estudo de Caso: Latência em Dependência Crítica 3.1 Nota metodológica O cenário que descrevo nesta seção é um estudo de caso construído para fins didáticos. A arquitetura, as configurações e os procedimentos refletem práticas reais de mercado. Os valores numéricos que apresento nas Tabelas 1 e 2 são ilustrativos: defini-os de modo a manter coerência interna entre as métricas, e eles não correspondem a medições de um ambiente produtivo específico. 3.2 Arquitetura do sistema A plataforma em que trabalho é composta por microsserviços desenvolvidos em Spring Boot e executados no Amazon Elastic Kubernetes Service (EKS), distribuídos em três zonas de disponibilidade na região sa-east-1 (São Paulo). A Figura 2 apresenta o fluxo de criação de pedidos, que consideramos o fluxo crítico do negócio. Figura 2 – Fluxo de criação de pedidos +-------------+ Cliente -------> | API Gateway | +------+------+ | +------v---------+ +-------------------+ | order-service | ----> | inventory-service | | (Spring Boot | | (Spring Boot) | | + Resilience4j)| +---------+---------+ +------+---------+ | | +-------v-------+ +------v--------+ | Amazon RDS | |payment-service| | (PostgreSQL) | +---------------+ +---------------+ Fonte: elaborado pelo autor. O order-service consulta o inventory-service de forma síncrona para verificar a disponibilidade de estoque antes de confirmar cada pedido. Por se tratar de uma dependência síncrona situada no caminho crítico, identifiquei sua degradação como o principal risco de propagação de falhas em nossa arquitetura. 3.3 Especificação do experimento A carta que selecionamos para o GameDay foi a REDE-07, cuja especificação apresento na Listagem 1. Listagem 1 – Especificação da carta REDE-07 id: REDE-07 naipe: rede severidade: 2 titulo: "Latência na Dependência Crítica" hipotese: > Se o inventory-service responder com acréscimo de 2000 ms de latência, a taxa de sucesso na criação de pedidos permanecerá acima de 99% e a latência p99 do order-service permanecerá abaixo de 800 ms, porque o Circuit Breaker será aberto e o fallback utilizará o cache de estoque. estado_estavel: - metrica: taxa_sucesso_pedidos referencia: ">= 99.5%" - metrica: latencia_p99_order_service referencia: "< 450 ms" - metrica: pedidos_por_minuto referencia: "variação < 5% em relação ao grupo de controle" variavel_injetada: tipo: latencia alvo: order-service -> inventory-service latencia_ms: 2000 jitter_ms: 300 percentual_trafego: 10 duracao: 10m ferramenta: toxiproxy blast_radius: ambiente: producao-canary escopo: "pods do order-service no grupo canary (5% dos usuários)" impacto_maximo: "aproximadamente 0,5% das requisições de criação de pedido" servicos_excluidos: [payment-service, auth-service] condicao_aborto: - "taxa de erro HTTP 5xx no canary > 2% por mais de 1 minuto" - "latência p99 no canary > 3000 ms por mais de 2 minutos" - "disparo de qualquer alerta de severidade P1" rollback: "remoção do toxic de latência no Toxiproxy" Fonte: elaborado pelo autor. 3.4 Delimitação do Blast Radius O Blast Radius corresponde à extensão máxima do impacto caso a hipótese se revele falsa. Neste experimento, delimitei-o em três dimensões complementares: 1. Ambiente: restringimos o experimento ao grupo canary, que recebe 5% do tráfego real por meio de roteamento ponderado no API Gateway. 2. Tráfego: dentro do grupo canary, submetemos à latência apenas 10% das chamadas ao inventory-service. 3. Tempo: fixamos a duração máxima em 10 minutos, com interrupção automática em caso de violação das condições de aborto. O produto dessas restrições resulta em um impacto máximo estimado de 0,5% das requisições de criação de pedido durante, no máximo, 10 minutos. Antes da execução, apresentei esse nível de risco à área de produto, que o aceitou formalmente. Optei pelo ambiente produtivo, e não apenas pelo de homologação (staging), com base no terceiro princípio do Chaos Engineering. Em minha experiência, volume de tráfego, padrões de acesso e dimensionamento de pools de conexão raramente são reproduzidos com fidelidade em homologação, e diversas fragilidades de resiliência só se manifestam sob carga real. Para equipes em estágio inicial de maturidade, contudo, considero o ambiente de homologação um ponto de partida adequado. 3.5 Injeção da falha Injetei a latência por meio do Toxiproxy, proxy TCP de código aberto desenvolvido pela Shopify para simulação de condições adversas de rede (SHOPIFY, 2024). Implantamos o proxy como contêiner auxiliar (sidecar) nos pods do order-service, interceptando as conexões destinadas ao inventory-service. A Listagem 2 apresenta o comando que utilizei. Listagem 2 – Injeção de latência com o Toxiproxy toxiproxy-cli toxic add \ --type latency \ --attribute latency=2000 \ --attribute jitter=300 \ --toxicity 0.1 \ --toxicName latency_inventory \ inventory Fonte: elaborado pelo autor. --- 4. Observabilidade e Resultados 4.1 Instrumentação Antes de injetar qualquer falha, precisei garantir que conseguíamos medir o estado estável. A instrumentação que utilizamos foi composta pelos seguintes elementos: - Micrometer e Prometheus: coleta de métricas dos serviços Spring Boot por meio do Spring Boot Actuator. - Grafana: painel que criei especificamente para o experimento, com exibição simultânea das métricas do grupo de controle e do grupo canary. - OpenTelemetry e Jaeger: rastreamento distribuído para identificar como o tempo de resposta se distribuía entre os serviços. - Alertmanager: avaliação contínua das condições de aborto. A Listagem 3 apresenta as consultas PromQL que utilizei para as principais métricas de controle. Listagem 3 – Consultas PromQL das métricas de controle # Latência p99 do order-service, segmentada por grupo histogram_quantile(0.99, sum(rate(http_server_requests_seconds_bucket{service="order-service", uri="/orders"}[1m])) by (le, group) ) # Taxa de erros HTTP 5xx, segmentada por grupo sum(rate(http_server_requests_seconds_count{service="order-service", status=~"5.."}[1m])) by (group) / sum(rate(http_server_requests_seconds_count{service="order-service"}[1m])) by (group) # Estado do Circuit Breaker (valor 1 indica estado aberto) resilience4j_circuitbreaker_state{name="inventory", state="open"} Fonte: elaborado pelo autor. 4.2 Primeira execução: refutação da hipótese A Listagem 4 apresenta a configuração de resiliência que estava vigente no order-service antes do experimento. Listagem 4 – Configuração original do Resilience4j resilience4j: circuitbreaker: instances: inventory: sliding-window-size: 100 failure-rate-threshold: 50 wait-duration-in-open-state: 30s Fonte: elaborado pelo autor. Só ao analisar essa configuração em retrospecto percebi que ela não definia limite de tempo para as chamadas remotas nem critério de classificação de chamadas lentas. O Circuit Breaker contabilizava apenas exceções, de modo que uma chamada concluída com sucesso após 2 segundos não era registrada como falha. A Tabela 1 apresenta as métricas que observei nos primeiros quatro minutos. Tabela 1 – Métricas da primeira execução | Métrica | Grupo de controle | Grupo canary | Referência | Resultado | |---|---|---|---|---| | Taxa de sucesso | 99,7% | 98,1% | ≥ 99,5% | Não atendido | | Latência p99 | 410 ms | 2.380 ms | < 450 ms | Não atendido | | Estado do Circuit Breaker | Fechado | Fechado | Abertura esperada | Não atendido | | Ocupação do pool de threads (Tomcat) | 22% | 91% | — | Anomalia | Fonte: dados ilustrativos elaborados pelo autor. Ao analisar os rastros no Jaeger, identifiquei o mecanismo de propagação da falha. As chamadas lentas ao inventory-service mantinham ocupadas as threads do servidor Tomcat. Com menos threads disponíveis, mesmo as requisições não submetidas à latência passaram a aguardar em fila. Assim, uma degradação aplicada a apenas 10% das chamadas comprometeu o desempenho de praticamente todo o grupo canary. A violação da condição de aborto relativa à latência p99 interrompeu o experimento automaticamente no quarto minuto. A remoção da latência no Toxiproxy levou menos de cinco segundos, e as métricas retornaram aos valores de referência em aproximadamente 40 segundos. Não interpreto a refutação da hipótese como insucesso do experimento, mas como seu resultado mais informativo. Com impacto limitado a cerca de 0,5% das requisições durante quatro minutos, identificamos uma fragilidade que, em um incidente real envolvendo a degradação do inventory-service, poderia comprometer a totalidade da criação de pedidos. 4.3 Medidas corretivas Para corrigir o problema, adotamos de forma combinada quatro padrões de resiliência descritos por Nygard (2018), implementados por meio da biblioteca Resilience4j (RESILIENCE4J, 2024). A Listagem 5 apresenta a configuração resultante. Listagem 5 – Configuração revisada do Resilience4j resilience4j: circuitbreaker: instances: inventory: sliding-window-size: 50 failure-rate-threshold: 50 slow-call-rate-threshold: 30 slow-call-duration-threshold: 500ms wait-duration-in-open-state: 15s permitted-number-of-calls-in-half-open-state: 5 timelimiter: instances: inventory: timeout-duration: 800ms bulkhead: instances: inventory: max-concurrent-calls: 20 Fonte: elaborado pelo autor. A Listagem 6 mostra como apliquei os padrões no código do serviço. Listagem 6 – Aplicação dos padrões de resiliência no order-service @CircuitBreaker(name = "inventory", fallbackMethod = "estoqueDoCache") @TimeLimiter(name = "inventory") @Bulkhead(name = "inventory", type = Bulkhead.Type.THREADPOOL) public CompletableFuture<Estoque> consultarEstoque(String produtoId) { return CompletableFuture.supplyAsync(() -> inventoryClient.buscar(produtoId)); } private CompletableFuture<Estoque> estoqueDoCache(String produtoId, Throwable ex) { log.warn("Fallback de estoque acionado para {}: {}", produtoId, ex.getMessage()); return CompletableFuture.completedFuture( estoqueCache.ultimoValorConhecido(produtoId).comFlagReconciliacao() ); } Fonte: elaborado pelo autor. Cada padrão cumpre uma função específica: - Time Limiter: impõe limite de 800 ms para cada chamada ao inventory-service, impedindo que threads permaneçam ocupadas indefinidamente. - Bulkhead: isola as chamadas ao inventory-service em um pool de threads dedicado, de modo que sua saturação não comprometa os demais fluxos do order-service. - Circuit Breaker com limiar de chamadas lentas: passa a considerar chamadas acima de 500 ms no cálculo de abertura do circuito, interrompendo tentativas contra uma dependência degradada. - Fallback: com o circuito aberto, o pedido é registrado com base no último valor de estoque conhecido no cache e marcado para reconciliação assíncrona. Essa foi uma decisão de negócio que tomamos em conjunto com a área de produto: consideramos preferível aceitar o pedido com pequeno risco de divergência de estoque a recusar a venda. 4.4 Segunda execução: confirmação da hipótese Após implantarmos as correções, executei novamente a carta REDE-07 com os mesmos parâmetros. A Tabela 2 apresenta os resultados. Tabela 2 – Métricas da segunda execução | Métrica | Grupo de controle | Grupo canary | Referência | Resultado | |---|---|---|---|---| | Taxa de sucesso | 99,7% | 99,6% | ≥ 99,5% | Atendido | | Latência p99 | 405 ms | 790 ms | < 800 ms (hipótese) | Atendido | | Estado do Circuit Breaker | Fechado | Aberto após ~20 s | Abertura esperada | Atendido | | Chamadas atendidas por fallback | 0% | ~9% | — | Conforme esperado | | Ocupação do pool de threads (Tomcat) | 21% | 26% | — | Normal | Fonte: dados ilustrativos elaborados pelo autor. Desta vez, o experimento transcorreu durante os 10 minutos previstos sem violar nenhuma condição de aborto. Observei o Circuit Breaker alternar entre os estados aberto e semiaberto conforme o esperado, e a latência p99 manteve-se imediatamente abaixo do limite imposto pelo Time Limiter. Faço, porém, uma ressalva: a latência p99 do grupo canary aumentou de aproximadamente 400 ms para 790 ms. A hipótese foi confirmada, mas o sistema não se tornou imune à falha; passou a degradar de forma controlada e previsível. Considero essa distinção central para a compreensão da resiliência, que não corresponde à ausência de falhas, mas à capacidade de manter o serviço em níveis aceitáveis durante sua ocorrência. 4.5 Incorporação ao processo contínuo Com a hipótese confirmada, incorporei a carta REDE-07 à nossa suíte de experimentos automatizados, e ela passou a ser executada semanalmente no grupo canary. Dessa forma, eventuais regressões, como a remoção acidental do Time Limiter em uma refatoração futura, serão detectadas antes de se manifestarem em um incidente real. Com essa etapa, atendemos ao quarto princípio do Chaos Engineering, que recomenda a automação contínua dos experimentos. --- 5. Conclusão A experiência relatada neste artigo me mostrou, na prática, que o Chaos Engineering cumpre a função de substituir suposições por evidências. Antes de executarmos a carta REDE-07, eu e minha equipe acreditávamos que o Circuit Breaker protegia o sistema contra a degradação do inventory-service. O experimento refutou essa crença e revelou um mecanismo de falha em cascata que nossos testes funcionais não teriam identificado. Desse experimento, extraio as seguintes lições: 1. A latência é mais danosa que a indisponibilidade. Um serviço indisponível falha rapidamente, enquanto um serviço lento consome recursos de forma silenciosa até comprometer os serviços que dele dependem. 2. A resiliência resulta da combinação de padrões. No caso que analisei, o Circuit Breaker sem limite de tempo foi ineficaz contra chamadas lentas. 3. Hipóteses refutadas são os resultados de maior valor. Experimentos que apenas confirmam o comportamento esperado produzem pouco conhecimento novo. 4. A observabilidade é pré-requisito do experimento. Sem a capacidade de medir o estado estável, a injeção de falhas deixa de ser experimentação e passa a ser apenas uma fonte de instabilidade. 5. A delimitação do Blast Radius viabiliza o aprendizado com baixo risco. Um impacto de aproximadamente 0,5% das requisições durante quatro minutos nos permitiu identificar uma falha com potencial de afetar a totalidade do fluxo de pedidos. No plano organizacional, percebi que o formato de baralho reduziu a percepção da prática como atividade de auditoria e favoreceu a participação conjunta das equipes de desenvolvimento e operações. Esse efeito reforçou, em nossa equipe, três fundamentos da cultura DevOps: a responsabilidade compartilhada, pois quem desenvolve o código passou a participar da análise de como ele falha em produção; o ciclo de retorno rápido, pois passamos a descobrir falhas em sessões controladas, e não durante plantões; e a melhoria contínua, pois cada hipótese refutada gera uma correção, e cada correção passa a ser verificada por um experimento automatizado. Para quem pretende iniciar essa prática, recomendo uma abordagem incremental: selecionar uma única dependência crítica, formular uma hipótese no padrão "Se... então... porque...", delimitar um Blast Radius reduzido, definir condições de aborto objetivas e conduzir o primeiro experimento em ambiente de homologação. Como próximos passos, pretendo estender a análise a cartas de maior severidade, como a perda de uma zona de disponibilidade, e avaliar quantitativamente o efeito do programa de experimentos sobre indicadores como o tempo médio de recuperação (MTTR) e a frequência de incidentes. --- Referências BASIRI, A. et al. Chaos Engineering. IEEE Software, v. 33, n. 3, p. 35-41, 2016. BEYER, B. et al. Site Reliability Engineering: how Google runs production systems. Sebastopol: O'Reilly Media, 2016. NYGARD, M. T. Release It!: design and deploy production-ready software. 2. ed. Raleigh: Pragmatic Bookshelf, 2018. PRINCIPLES OF CHAOS ENGINEERING. Principles of Chaos Engineering. 2019. Disponível em: principlesofchaos.org. Acesso em: 15 out. 2026. RESILIENCE4J. Resilience4j documentation. 2024. Disponível em: resilience4j.readme.io. Acesso em: 15 out. 2026. ROSENTHAL, C.; JONES, N. Chaos Engineering: system resiliency in practice. Sebastopol: O'Reilly Media, 2020. SHOPIFY. Toxiproxy. 2024. Disponível em: Shopify/toxiproxy. Acesso em: 15 out. 2026.