DEV Community: Stephen Tsoi

Launching My Tech Docs Hub: 2 Years, 100+ Articles on Systems Architecture, EDA, and Observability 🚀

Stephen Tsoi — Tue, 22 Sep 2026 13:46:05 +0000

Hi everyone! I’m incredibly excited to share that I have officially made my technical documentation hub public.

Over the past two years, I’ve been quietly building and refining a comprehensive knowledge base covering modern software engineering, distributed systems, and production excellence. What started as a personal repository for my own notes has grown into a massive collection of design guides, best practices, and real-world lessons learned.

Today, the hub hosts over 100 technical articles (with new content continuously being added). Some pieces are still a work in progress, but I wanted to open the doors to the community today.

📖 What's Inside the Hub?

Enterprise Integration & Patterns: Core fundamentals, architectural principles, and technology-agnostic deep dives.
Event-Driven Architecture & Messaging: Event-driven design patterns, streaming concepts, distributed systems, persistence, and reliability guarantees.
Production Messaging Troubleshooting: Practical diagnostics, production support runbooks, and RCA approaches for complex environments.
OpenTelemetry & Observability: Distributed tracing, metrics, logging strategies, and end-to-end implementation patterns.
Security Architecture: Secure integration patterns and enterprise security best practices.
Notification Frameworks: Multi-channel architectures, scalability, and event-driven notification design.

🌟 GitBook as the "Source of Truth"
While I love cross-posting selected articles here on Hashnode and DEV Community to connect with the broader community, my GitBook site serves as the ultimate Source of Truth. It contains the latest revisions, the most complete content library, and early-access articles that haven't been shared anywhere else yet.

🤝 I'd Love Your Feedback!
I built this platform to serve as both a personal reference library and a valuable resource for architects, developers, and platform engineers tackling distributed systems.

Please explore it, bookmark it, and let me know what you think! I’d love to hear your feedback, suggestions, or chat about any of the topics covered.
[👉 Link to your GitBook Hub here]

🔍 Why Do We Need OpenTelemetry Tracing?

Stephen Tsoi — Tue, 15 Sep 2026 14:31:04 +0000

Whether your organization adopts a Request-Driven Architecture (RDA) or an Event-Driven Architecture (EDA), a single business transaction often traverses multiple applications, APIs, networks, message brokers, cloud services, and infrastructure components before reaching its destination.

When a production incident occurs, how much time does your team spend answering a seemingly simple question:

"Where exactly did the transaction fail?"

Unfortunately, finding the answer is rarely simple.

😖 Common Challenges in Incident Troubleshooting

Traditional monitoring and troubleshooting approaches often struggle because:

🔸 Most APM solutions are service-focused rather than business transaction-focused

🔸 Root cause analysis relies heavily on application logs

🔸 Different systems use different business identifiers and logging standards

🔸 There is often no global correlation key across applications

🔸 Limited visibility into third-party components such as:

API Gateways Message Brokers Load Balancers Network Infrastructure SaaS Platforms

As a result, engineers spend more time correlating information than resolving the actual issue.

🌐 The OpenTelemetry Advantage

OpenTelemetry has become the de facto open standard for observability and is supported by a broad ecosystem of vendors and technologies.

Here's how it works:

🟢 A Trace ID is created at the entry point of a request or event.

🟢 The same Trace ID is propagated throughout the entire transaction journey.

🟢 Every participating component generates its own Span with a unique Span ID.

🟢 All spans are then stitched together to provide a complete end-to-end transaction view.

Instead of manually correlating isolated logs across multiple systems, teams can visualize the entire business transaction from end to end, enabling faster troubleshooting and root cause analysis.

✅ Key Benefits of OpenTelemetry Tracing

End-to-End Transaction Visibility - Track a business transaction across multiple systems and environments. Faster Root Cause Analysis - Quickly identify where latency, errors, or failures occur. Broad Industry Support - Supported by most major observability and APM platforms. Technology Agnostic - Works across diverse programming languages, frameworks, and protocols. Reduced Vendor Lock-In - Adopt an open standard instead of being tied to proprietary tracing solutions. Cross-Domain Correlation - Correlate applications, APIs, messaging platforms, infrastructure, and network services with a single Trace ID.

💡 Final Thought

In modern distributed architecture, the challenge is no longer collecting more logs, metrics, or alerts.

The real challenge is understanding how a business transaction traverses dozens of interconnected systems and where it breaks down when things go wrong.

OpenTelemetry shifts observability from a system-centric view to a business transaction-centric view, enabling teams to troubleshoot faster, improve reliability, and deliver a better customer experience.

If logs tell you what happened and metrics tell you how often it happened, tracing tells you exactly how it happened.

🔔 Looking for more content like this? I share exclusive insights and tech summaries weekly on my LinkedIn Newsletter. Subscribe here to join the conversation!

🚀 Stop Selling Event-Driven Architecture. Start Selling Business Outcomes

Stephen Tsoi — Sun, 13 Sep 2026 08:33:42 +0000

👋 Hi dev community! I originally published this on my LinkedIn Newsletter, but wanted to share it with the dev community here to get your thoughts on how your engineering teams handle infrastructure ROI. Let's discuss in the comments!

Why are the best EDA initiatives funded through business value, not technical excellence.

Many organizations view Event-Driven Architecture (EDA) as a technology modernization initiative focused on event streams, messaging platforms, and real-time integration. While these capabilities are important, they rarely justify investment on their own.

Business leaders fund outcomes, not architecture. One of the biggest challenges in securing EDA investment is focusing too heavily on technical benefits such as scalability, decoupling, and architectural elegance. These matter to technology teams, but business stakeholders are more interested in the impact on business performance, customer experience, operational efficiency, and risk management.

The key question is simple: "How will this improve business outcomes?" If we cannot answer that clearly, gaining support and funding becomes difficult.

For more insights, see my newsletter: "Event-Driven Architecture: Aligning Technology with Business Outcomes."

Start with the Business Problem

From my experience, successful EDA adoption starts with understanding business challenges, not promoting technology.

Conduct a thorough analysis of stakeholder use cases and current operational or system pain points. Then demonstrate how EDA can improve information flow, increase responsiveness, and remove bottlenecks.

This is where many IT teams and vendors fail. They focus on explaining the technology rather than the business value. Business leaders invest in outcomes, not architecture.

The technology remains the same, but the story becomes relevant to those making investment decisions.

Start Small and Prove the Value

Large-scale transformation programs often struggle because they ask stakeholders to commit significant investment before any value has been demonstrated.

A more effective approach is to identify a small but high-value use case and establish a proof of concept. When stakeholders see tangible improvements, support often expands organically to other business domains.

Four Lessons Learned from Driving EDA Adoption

Tailor the Conversation to Each Stakeholder

Not all stakeholders care about the same outcomes. Using the same narrative for every audience is rarely effective.

Instead, align the discussion with the objectives and success metrics that matter most to each stakeholder group.

Understand the Business and System Landscape Thoroughly

To build credibility, you need more than architectural knowledge.

You should understand:

Business processes
System interactions
Upstream and downstream dependencies
Data flows
Operational constraints
Regulatory considerations

Stakeholders frequently ask questions that extend beyond the immediate solution. Being prepared to discuss the broader landscape demonstrates ownership and builds confidence in the proposed approach.

Use Real Numbers Whenever Possible

One of the most effective ways to gain support is to quantify the expected benefits.

Avoid statements such as:

"The process will be much faster."
"The system will be more efficient."
"Users will have a better experience."

Instead, use measurable outcomes:

Reduce processing time from 4 hours to 5 minutes.
Improve customer notification speed from next-day to near real-time.
Reduce manual intervention by 60%.

Numbers transform assumptions into business cases.

Translate Technical Concepts into Business Language

Many stakeholders are not interested in technical architecture diagrams.

That does not mean they lack expertise.

In fact, they often possess a deep understanding of the business processes and systems they manage every day. When people understand the outcome, they become far more willing to support the solution.

They invest in better business outcomes that Event-Driven Architecture makes possible.

Takeaway

The fastest way to gain support for EDA is to stop selling architecture and start telling a business story. When stakeholders can clearly see the operational, financial, or customer benefits, funding conversations become significantly easier and adoption follows naturally.

📩 Stay Ahead of the Curve If you enjoyed these practical insights on Event-Driven Architecture, APIs, observability, and digital transformation, consider subscribing to my newsletter on LinkedIn.

👉 Subscribe to the LinkedIn Newsletter here to get the next framework directly in your feed!

What are your thoughts on EDA as a cost-saving mechanism? Let’s debate in the comments below!

🥇The Real Value of Event-Driven Architecture Isn't Technology. It's Cost Reduction.

Stephen Tsoi — Sat, 12 Sep 2026 14:03:54 +0000

How Event-Driven Architecture (EDA) Significantly Reduces Enterprise IT Costs

In today's digital world, business users expect new features and services to be delivered faster than ever before, with minimal risk and within increasingly constrained budgets.

Unfortunately, traditional Request-Driven Architecture (RDA) often struggles to meet these expectations. As organizations scale, integration complexity, infrastructure costs, and operational overhead continue to grow, making even small changes expensive and time-consuming.

This is where Event-Driven Architecture (EDA) creates a significant advantage.

EDA is not just a modern integration pattern. It is a strategic approach that helps organizations reduce costs, accelerate delivery, and improve scalability while maintaining flexibility for future growth.

⚠️ Why Traditional Architecture Is Expensive

🌐 Complex Infrastructure

Traditional enterprise systems typically require multiple layers of infrastructure to support point-to-point communication between applications, including:

🔥 Firewalls
⚖️ Load Balancers
🛡️ Proxy Servers
🌍 Multiple Network Segments
🖥️ Dedicated Integration Components

As the number of applications grows, the supporting infrastructure grows with it. The result is higher hardware costs, increased operational effort, and greater complexity.

🔗 Integration Sprawl

Most traditional environments are built around tightly coupled point-to-point integrations.

Every application needs to know:

Who to connect to
Which protocol to use
What data format to exchange
How to handle failures and retry
How to buffer messages when a target system is unavailable

As new systems are added, the number of interfaces grows exponentially.

For an enterprise with hundreds of services, maintaining thousands of interfaces becomes a major cost driver.

Even a seemingly simple change to a single data element may require modifications and testing across many dependent systems.

Business Impact

💰 Higher development costs
✅ Extensive No-Harm Testing Requirements
🛠️ Increased maintenance effort
⚠️ Greater implementation risk
🕒 Longer project timelines
📊 Additional monitoring and compliance costs
⏳ Slow and Expensive Change Delivery

💡 Ultimately, the largest cost in enterprise IT is not infrastructure or software licenses. It is the cost of change.

The more connected and tightly coupled systems become, the more expensive every change becomes. EDA addresses this challenge by enabling systems to evolve independently, significantly reducing the cost, effort, and risk of change.

🚀 How EDA Reduces Costs

Organizations can address these challenges by implementing an Event Mesh, which securely connects applications across multiple network environments while providing a scalable foundation for self-service integration.

Combined with microservices, automation, and DevOps practices, EDA enables a much more efficient operating model.

The cost savings are substantial.

🔗 1. Reducing Integration Costs

Event-Driven Architecture (EDA) breaks down traditional, complex point-to-point integrations into multiple simpler, reusable interfaces. Events can be shared across different services rather than requiring dedicated integrations for each consuming application.

This approach significantly simplifies solution design, development, testing, support, and ongoing maintenance, resulting in a lower Total Cost of Ownership (TCO).

In large enterprises, integration development, testing, and maintenance can consume a significant portion of project budgets. By promoting reusable event streams and loose coupling, EDA can substantially reduce these ongoing integration costs.

🏗️ 2. Lower Infrastructure Costs

EDA simplifies communication between systems through a shared messaging platform.

Using capabilities such as:

📬 Exclusive Queues
📩 Non-Exclusive Queues
📢 Publish/Subscribe Messaging

Organizations can significantly reduce the need for:

Additional load balancers
Complex integration gateways
Dedicated communication infrastructure

Result

✅ Lower hardware investment
✅ Reduced software licensing costs
✅ Simplified infrastructure management

📶 3. Optimizing Network and Bandwidth Usage

Many traditional integration solutions repeatedly exchange request/response messages or data synchronization payloads, even when only a small subset of data has changed.

EDA works differently.

Events are transmitted when changes occur.

Consumers subscribe only to the events they need.

Result

✅ Smaller message sizes
✅ Less network traffic
✅ Reduced bandwidth consumption
✅ Improved overall efficiency

This translates directly into lower infrastructure and operational costs.

⚙️ 4. Lower Operational Costs

In an EDA environment, applications communicate through the event mesh instead of maintaining direct relationships with numerous systems.

This greatly simplifies operations.

Teams no longer need to manage thousands of dependencies or firewall rules between applications.

Result

✅ Simpler architecture
✅ Reduced operational effort
✅ Faster problem resolution
✅ Lower support costs
✅ Improved system scalability

⏱️ 5. Faster Delivery Equals Lower Cost

Perhaps the most overlooked benefit of EDA is the reduction in delivery time.

Because systems are loosely coupled:

Teams can work independently.
New consumers can subscribe without impacting producers.
Changes can be deployed with less regression testing.
Business capabilities can evolve at their own pace

Result

✅ Faster time-to-market
✅ Lower project costs
✅ Reduced implementation risk
✅ Greater business agility

🧩 6. Increased Reusability and Economies of Scale

Events can be reused by multiple consumers simultaneously. As adoption grows, the cost of producing an event remains relatively constant while the business value generated by that event continues to increase. This creates economies of scale that are difficult to achieve with traditional point-to-point integrations. Each additional consumer can leverage existing events without requiring new integrations, allowing organizations to increase business value while minimizing incremental delivery costs.

🎯 Final Thoughts

When discussing Event-Driven Architecture, many people focus on technology. However, the real value of EDA is not technology alone. The real value is cost reduction.

By simplifying integrations, reducing infrastructure requirements, lowering operational overhead, minimizing network complexity, and accelerating delivery, EDA enables organizations to do more with less.

In our experience, EDA is not merely an architectural evolution. It is a practical strategy for reducing Total Cost of Ownership while increasing agility and scalability.

💡 The true power of EDA is not simply connecting systems. It is enabling change at a lower cost, with lower risk, and at greater speed. In today's digital economy, the organizations that can change fastest are often the ones that win.

📩 Stay Ahead of the Curve If you enjoyed these practical insights on Event-Driven Architecture, APIs, observability, and digital transformation, consider subscribing to my newsletter on LinkedIn.

👉 Subscribe to the LinkedIn Newsletter here to get the next framework directly in your feed!

What are your thoughts on EDA as a cost-saving mechanism? Let’s debate in the comments below!