[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-21-arquitectura-eventos-rust-patron-bus":3},{"article":4,"author":42},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":22,"related_articles":23},"d8000000-0000-0000-0000-000000000121","a0000000-0000-0000-0000-000000000086","Deep EVM #21: Arquitectura Dirigida por Eventos en Rust — Patrón Bus para Sistemas en Tiempo Real","deep-evm-21-arquitectura-eventos-rust-patron-bus","Implementa un bus de eventos en Rust para sistemas en tiempo real: publicar\u002Fsuscribir con tokio broadcast, desacoplamiento de componentes, y patrones para bots de MEV y pipelines de datos.","## El patrón de bus de eventos\n\nEn sistemas complejos como bots de MEV o pipelines de datos, los componentes necesitan comunicarse sin acoplamiento directo. El patrón de bus de eventos proporciona esta desvinculación: los productores publican eventos sin saber quién escucha, y los consumidores se suscriben sin saber quién produce.\n\n## Implementación con tokio::broadcast\n\n```rust\nuse tokio::sync::broadcast;\n\n#[derive(Clone, Debug)]\nenum Event {\n    NewBlock(BlockData),\n    NewTransaction(TxData),\n    ArbitrageFound(ArbOpportunity),\n    BundleSubmitted(BundleResult),\n}\n\nstruct EventBus {\n    sender: broadcast::Sender\u003CEvent>,\n}\n\nimpl EventBus {\n    fn new(capacity: usize) -> Self {\n        let (sender, _) = broadcast::channel(capacity);\n        Self { sender }\n    }\n    \n    fn publish(&self, event: Event) {\n        let _ = self.sender.send(event);\n    }\n    \n    fn subscribe(&self) -> broadcast::Receiver\u003CEvent> {\n        self.sender.subscribe()\n    }\n}\n```\n\n## Componentes desacoplados\n\nCada componente del sistema se suscribe solo a los eventos que le interesan:\n\n```rust\n\u002F\u002F Componente: detector de arbitraje\nasync fn arbitrage_detector(bus: Arc\u003CEventBus>) {\n    let mut rx = bus.subscribe();\n    \n    while let Ok(event) = rx.recv().await {\n        if let Event::NewBlock(block) = event {\n            let opportunities = find_arbitrage(&block).await;\n            for opp in opportunities {\n                bus.publish(Event::ArbitrageFound(opp));\n            }\n        }\n    }\n}\n\n\u002F\u002F Componente: simulador\nasync fn simulator(bus: Arc\u003CEventBus>) {\n    let mut rx = bus.subscribe();\n    \n    while let Ok(event) = rx.recv().await {\n        if let Event::ArbitrageFound(opp) = event {\n            let result = simulate(opp).await;\n            if result.is_profitable() {\n                bus.publish(Event::BundleSubmitted(\n                    submit_bundle(result).await\n                ));\n            }\n        }\n    }\n}\n```\n\n## Ventajas de esta arquitectura\n\n1. **Desacoplamiento** — Los componentes no se conocen entre sí\n2. **Escalabilidad** — Añadir nuevos consumidores no afecta a los productores\n3. **Testing** — Cada componente se puede testear independientemente\n4. **Resiliencia** — Si un consumidor falla, los demás continúan\n\n## Manejo de backpressure\n\nCuando los consumidores no pueden procesar eventos a la velocidad de producción, el canal broadcast descarta mensajes antiguos. Usa canales con capacidad adecuada y monitorea los retrasos.\n\n## Conclusión\n\nLa arquitectura de bus de eventos con tokio::broadcast es ideal para sistemas Rust en tiempo real. El desacoplamiento entre componentes facilita el desarrollo, testing y mantenimiento de sistemas complejos como bots de MEV y pipelines de datos de blockchain.","\u003Ch2 id=\"el-patr-n-de-bus-de-eventos\">El patrón de bus de eventos\u003C\u002Fh2>\n\u003Cp>En sistemas complejos como bots de MEV o pipelines de datos, los componentes necesitan comunicarse sin acoplamiento directo. El patrón de bus de eventos proporciona esta desvinculación: los productores publican eventos sin saber quién escucha, y los consumidores se suscriben sin saber quién produce.\u003C\u002Fp>\n\u003Ch2 id=\"implementaci-n-con-tokio-broadcast\">Implementación con tokio::broadcast\u003C\u002Fh2>\n\u003Cpre>\u003Ccode class=\"language-rust\">use tokio::sync::broadcast;\n\n#[derive(Clone, Debug)]\nenum Event {\n    NewBlock(BlockData),\n    NewTransaction(TxData),\n    ArbitrageFound(ArbOpportunity),\n    BundleSubmitted(BundleResult),\n}\n\nstruct EventBus {\n    sender: broadcast::Sender<Event>,\n}\n\nimpl EventBus {\n    fn new(capacity: usize) -> Self {\n        let (sender, _) = broadcast::channel(capacity);\n        Self { sender }\n    }\n    \n    fn publish(&self, event: Event) {\n        let _ = self.sender.send(event);\n    }\n    \n    fn subscribe(&self) -> broadcast::Receiver<Event> {\n        self.sender.subscribe()\n    }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"componentes-desacoplados\">Componentes desacoplados\u003C\u002Fh2>\n\u003Cp>Cada componente del sistema se suscribe solo a los eventos que le interesan:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-rust\">\u002F\u002F Componente: detector de arbitraje\nasync fn arbitrage_detector(bus: Arc<EventBus>) {\n    let mut rx = bus.subscribe();\n    \n    while let Ok(event) = rx.recv().await {\n        if let Event::NewBlock(block) = event {\n            let opportunities = find_arbitrage(&block).await;\n            for opp in opportunities {\n                bus.publish(Event::ArbitrageFound(opp));\n            }\n        }\n    }\n}\n\n\u002F\u002F Componente: simulador\nasync fn simulator(bus: Arc<EventBus>) {\n    let mut rx = bus.subscribe();\n    \n    while let Ok(event) = rx.recv().await {\n        if let Event::ArbitrageFound(opp) = event {\n            let result = simulate(opp).await;\n            if result.is_profitable() {\n                bus.publish(Event::BundleSubmitted(\n                    submit_bundle(result).await\n                ));\n            }\n        }\n    }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"ventajas-de-esta-arquitectura\">Ventajas de esta arquitectura\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>Desacoplamiento\u003C\u002Fstrong> — Los componentes no se conocen entre sí\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Escalabilidad\u003C\u002Fstrong> — Añadir nuevos consumidores no afecta a los productores\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Testing\u003C\u002Fstrong> — Cada componente se puede testear independientemente\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Resiliencia\u003C\u002Fstrong> — Si un consumidor falla, los demás continúan\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"manejo-de-backpressure\">Manejo de backpressure\u003C\u002Fh2>\n\u003Cp>Cuando los consumidores no pueden procesar eventos a la velocidad de producción, el canal broadcast descarta mensajes antiguos. Usa canales con capacidad adecuada y monitorea los retrasos.\u003C\u002Fp>\n\u003Ch2 id=\"conclusi-n\">Conclusión\u003C\u002Fh2>\n\u003Cp>La arquitectura de bus de eventos con tokio::broadcast es ideal para sistemas Rust en tiempo real. El desacoplamiento entre componentes facilita el desarrollo, testing y mantenimiento de sistemas complejos como bots de MEV y pipelines de datos de blockchain.\u003C\u002Fp>\n","es","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:31.630911Z","Arquitectura Dirigida por Eventos en Rust — Patrón Bus para Sistemas en Tiempo Real","Bus de eventos en Rust con tokio broadcast: pub\u002Fsub, desacoplamiento de componentes y patrones para sistemas en tiempo real.","Rust arquitectura eventos",null,"index, follow",[],"Ingeniería",[24,30,36],{"id":25,"title":26,"slug":27,"excerpt":28,"locale":12,"category_name":22,"published_at":29},"d0000000-0000-0000-0000-000000000683","Por qué Bali se está convirtiendo en el hub de impact-tech del Sudeste Asiático en 2026","por-que-bali-hub-impact-tech-sudeste-asiatico-2026","Bali ocupa el puesto 16 entre los ecosistemas startup del Sudeste Asiático. Con una concentración creciente de constructores Web3, startups de AI sostenible y empresas de eco-travel tech, la isla se consolida como capital de impact-tech de la región.","2026-03-28T10:44:49.926489Z",{"id":31,"title":32,"slug":33,"excerpt":34,"locale":12,"category_name":22,"published_at":35},"d0000000-0000-0000-0000-000000000682","El mosaico de protección de datos de ASEAN: checklist de cumplimiento para desarrolladores","mosaico-proteccion-datos-asean-checklist-cumplimiento-desarrolladores","Siete países de ASEAN tienen ahora leyes integrales de protección de datos, cada una con diferentes modelos de consentimiento, requisitos de localización y estructuras de sanciones. Un checklist práctico de cumplimiento para desarrolladores.","2026-03-28T10:44:49.919345Z",{"id":37,"title":38,"slug":39,"excerpt":40,"locale":12,"category_name":22,"published_at":41},"d0000000-0000-0000-0000-000000000681","La transformación digital de 29 mil millones de dólares de Indonesia: oportunidades para empresas de software","transformacion-digital-29-mil-millones-dolares-indonesia-oportunidades-empresas-software","El mercado de servicios IT de Indonesia alcanzará los 29.030 millones de dólares en 2026, frente a los 24.370 millones de 2025. La infraestructura cloud, la AI, el comercio electrónico y los centros de datos impulsan el crecimiento más rápido del Sudeste Asiático.","2026-03-28T10:44:49.897658Z",{"id":13,"name":43,"slug":44,"bio":45,"photo_url":19,"linkedin":19,"role":46,"created_at":47,"updated_at":47},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]