{"id":4702,"date":"2026-08-28T01:15:27","date_gmt":"2026-08-28T04:15:27","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/08\/28\/speaker-designing-systems-that-contain-failure-cs-week-peru-2026\/"},"modified":"2026-08-28T01:15:27","modified_gmt":"2026-08-28T04:15:27","slug":"speaker-designing-systems-that-contain-failure-cs-week-peru-2026","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/08\/28\/speaker-designing-systems-that-contain-failure-cs-week-peru-2026\/","title":{"rendered":"Speaker – Designing Systems That Contain Failure – CS Week Per\u00fa 2026"},"content":{"rendered":"
Designing Systems That Contain Failure \u2014 CS Week Per\u00fa 2026<\/p>\n

On August 13, 2026, I had the opportunity to speak at CS Week Per\u00fa 2026, an event organized by IEEE Computer Society student chapters across Peru.
\nMy session was:
\n\u201cIsolation and Trust Boundaries in Production: Designing Systems That Contain Failure\u201d
\nThe talk explored how production systems can be designed to limit the impact of failures through explicit trust boundaries, architectural invariants, and evidence-based validation.
\nThe central idea was simple:
\nThe goal isn’t to prevent every failure. The goal is to control its blast radius.
\nProduction systems fail. Requests overlap, processes crash, memory is exhausted, credentials can be compromised, and dependencies can become unavailable.
\nReliable engineering is not about assuming that none of these things will happen.
\nIt is about deciding what can be affected when they do.
\nA green unit-test suite demonstrates that the tested units behave correctly under the conditions we defined.
\nBut it does not necessarily demonstrate that the system as a whole preserves its architectural properties under concurrency, multiple tenants, resource exhaustion, or real deployment conditions.
\nA function can be correct in isolation while the system still violates an important invariant.
\nThat led to one of the central questions of the talk:
\nWhat properties must never be violated?
\nI used the concept of a Trust Boundary to make architectural assumptions explicit.
\nFor each boundary, we can ask three questions:
\nWhat are we protecting?
\nWhat is allowed to cross the boundary?
\nWhat happens if the condition is violated?
\nFrom there, we can define invariants: properties that the system must preserve under the conditions established by its design.
\nIn the architecture discussed during the session, three dimensions were particularly important:
\nContext \u2192 Logical isolation
\nIdentity \u2192 Cryptographic isolation
\nExecution \u2192 Physical\/process isolation
\nEach addresses a different class of failure.
\nIn asynchronous runtimes, multiple executions can share the same process.
\nUsing global mutable state for request-specific information can therefore create context contamination.
\nConceptually:
\nRequest A \u2192 tenant = A
\nRequest A awaits I\/O
\nRequest B \u2192 tenant = B
\nRequest A resumes
\nWhich tenant does it see?
\nThe process can be shared.
\nThe logical context shouldn’t be.
\nIn Python, ContextVar provides an execution-context mechanism that can help maintain request-specific state across asynchronous execution.
\nBut there is an important boundary:
\nContextVar is logical isolation, not process isolation.
\nIt does not create a memory sandbox or protect the process from resource exhaustion.
\nThat distinction becomes important when we move to the next boundary.
\nThe second question is:
\nHow do we ensure that an operation belongs to the expected tenant?
\nA single shared cryptographic secret creates a broad trust domain.
\nA more constrained architecture can derive tenant-specific cryptographic material from a protected root of trust.
\nThe important property is not simply \u201cusing HMAC\u201d.
\nThe important property is reducing the cryptographic blast radius.
\nIf one derived key is compromised, that compromise should not automatically expose the keys belonging to other tenants or reveal the root key.
\nThere is another important detail here:
\nHMAC does not prevent replay by itself.
\nAuthenticity and integrity are different from freshness.
\nA robust request-validation scheme can therefore combine mechanisms such as:
\nHMAC + Timestamp \/ Acceptance Window + Nonce \/ Replay Detection
\nEach mechanism protects a different property.
\nEventually, logical isolation reaches its limits.
\nImagine a tenant submits work that consumes excessive memory.
\nContextVar cannot protect the rest of the application from an out-of-memory condition.
\nThis is where a stronger execution boundary becomes useful.
\nThe control plane can delegate potentially expensive or unreliable work to an independent worker process or container with its own execution lifecycle and explicit resource limits.
\nIf that worker crashes or is terminated because it exceeds its limits, the control plane can remain available.
\nThis reduces the blast radius of the failure.
\nBut again, the boundary has limits.
\nA process boundary does not automatically protect against:
\nqueue saturation
\ndatabase exhaustion
\nnetwork congestion
\nshared infrastructure failures
\nexcessive request rates
\nA boundary contains specific classes of failure. It does not eliminate failure.
\nThis is where architecture becomes engineering.
\nA design isn’t fully validated because it works on a developer laptop.
\nThe environment where the system actually runs is part of the system.
\nFor the system discussed in the session, the architecture is deployed on Azure Functions, so the validation had to account for real execution conditions such as:
\nconcurrent invocations
\nprocess reuse
\nexternal services
\nephemeral execution
\nreal authentication and cryptographic material
\nproduction infrastructure
\nThe validation process can be summarized as:
\nInvariant \u2192 Implementation \u2192 Deployment \u2192 End-to-End Validation \u2192 Observable Evidence
\nThe objective isn’t to claim that a test suite proves a system is perfect.
\nThe objective is to obtain observable evidence that the defined properties remain true under the conditions we evaluated.
\nFor this system, the integration suite runs against the deployed environment rather than only against local mocks.
\nThe suite currently contains 61 checks covering different integration and execution scenarios, including external services, webhooks, MCP interactions, errors, concurrency, and other production-oriented cases.
\nThe result:
\n61 \/ 61 PASSED
\nThat number doesn’t mean the system is mathematically proven to be perfect.
\nIt means that, under the scenarios covered by the suite, the expected properties held in the deployed environment.
\nThat distinction matters.
\nTests provide evidence. They don’t provide absolute certainty.
\nOne of the ideas I wanted to leave with the audience was this:
\nA boundary doesn’t eliminate risk. It defines how we contain it.
\nInstead of asking only:
\n\u201cCan this component fail?\u201d
\nAsk:
\n\u201cWhat can this component affect when it fails?\u201d
\nThat question changes how we think about architecture.
\nIt makes us consider:
\nwhere state lives
\nwhere identity is established
\nwhere resources are bounded
\nwhere processes begin and end
\nwhat happens when a boundary is violated
\nhow we can verify those assumptions in production
\nThe goal isn’t to build systems where nothing ever fails.
\nThe goal is to build systems where failures have defined boundaries.
\nPrevent what you can. Contain what you can’t.
\nI’m grateful to the CS Week Per\u00fa community and the IEEE Computer Society chapters involved in the event for the opportunity to share these ideas and discuss production systems, security boundaries, and software architecture with other engineers and technology professionals.
\nThis talk also represents a direction I’m increasingly interested in: engineering systems at the intersection of software, distributed systems, embedded computing, and Cyber-Physical Systems.
\nI’ll continue documenting that work here.
\nThe original event information and speaker details are available through the official CS Week Per\u00fa 2026 channels.
\nI also wrote a detailed technical article about the architecture, trust boundaries, invariants, and production validation discussed in this session.
\n\u2192 Isolation and Trust Boundaries in Production \u2014 Technical Deep Dive
\nI document my work and ideas on software, systems, embedded engineering, and Cyber-Physical Systems on my personal blog.
\n\u2192 jafa.dev<\/p><\/div>\n

Fuente: Art\u00edculo original<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Designing Systems That Contain Failure \u2014 CS Week Per\u00fa 2026 On August 13, 2026, I had the opportunity to speak at CS Week Per\u00fa 2026, an event organized by IEEE Computer Society student chapters across Peru. My session was: \u201cIsolation and Trust Boundaries in Production: Designing Systems That Contain Failure\u201d The talk explored how production […]<\/p>\n","protected":false},"author":1,"featured_media":4701,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"webixso_pending_account_ids":""},"categories":[41],"tags":[],"class_list":["post-4702","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devto"],"jetpack_publicize_connections":[],"_links":{"self":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/4702","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/comments?post=4702"}],"version-history":[{"count":0,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/4702\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media\/4701"}],"wp:attachment":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media?parent=4702"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/categories?post=4702"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/tags?post=4702"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}