Why a Target Company’s Event-Driven Architecture Signals M&A Tech Risk (or Opportunity)

Tech M&A deals move fast. But before you sign, there’s one question you should ask: *How does this company handle events?*

Not marketing events. Not product launches. I mean **event-driven architecture** — the invisible wiring that determines how systems react to user logins, transactions, data updates, and API calls.

As an M&A tech due diligence consultant, I’ve seen companies with beautiful frontends, great revenue, and a cult following — only to stumble post-acquisition because their event systems were brittle, undocumented, or outright broken.

Here’s what I look for when evaluating a target’s event infrastructure — and why it can make or break the deal.

Why Event-Driven Architecture Exposes Hidden Tech Debt

Event-driven architecture (EDA) connects services through messages, not direct calls. Think: “When an order is placed, send an ‘OrderCreated’ event” instead of “Call the payment service.”

This style is **critical** for modern systems. It keeps services independent, reduces cascading failures, and makes it easier to add new features. But in M&A, it’s also a mirror:

A strong EDA tells you the company:

• Handles spikes without crashing (think product launches or Black Friday).
• Keeps services running even when parts fail (resilience).

<

• Ships features faster without breaking core workflows.

But a weak EDA? It hides:

• Systems that seem to work — until the message queue stops (and no one notices).
• Lost data, missed payments, and broken workflows (because events were lost).
• Engineers stuck debugging instead of building (the cost of “it works on my machine”).

Red Flag #1: “Eventual Consistency” Is a Band-Aid

I recently audited a company whose order system used Kafka to decouple payment and fulfillment. Sounds solid, right?

But there was no retry logic. No dead-letter queue (DLQ) handling. If a message failed, it was gone. Poof.

Here’s what their code looked like:


// ❌ BAD: No retry, no DLQ
kafkaConsumer.on('message', (msg) => {
processOrder(msg);
});


At low volume, it worked. But scale it to a busy **coin show registration system** with thousands of attendees? You’d get lost orders, duplicate charges, and angry customers.

This isn’t a scalability issue — it’s a **reliability time bomb**.

**What to do:** Ask for logs, monitoring, and retry policies. If they can’t show you retry counts, error rates, or escalation paths? That’s a major red flag.

Red Flag #2: Event Schemas That Keep Changing

Schema drift is one of the most common — and dangerous — problems in event systems.

I once reviewed a **collector coin show platform** (like PCGS Irvine) where the “AttendeeRegistered” event changed 17 times in 18 months. No versioning. No schema registry. No backward compatibility.

Result? Downstream systems — badge printing, parking validation, session tracking — kept breaking.

This isn’t just a tech issue. It’s a **business continuity risk**. If you’re integrating this into your own event management platform, you could lose data, fail compliance checks (missing attendee records), or worse — ruin customer trust.

**What to do:** Demand a **schema registry** (like Confluent Schema Registry), enforce **Avro or Protobuf**, and confirm **contract testing** in CI/CD. If they don’t have these? Assume integration will be painful.

Can This System Handle 10x Growth? (Not Just 10,000 Users)

Scalability isn’t just about handling traffic. It’s about how the system behaves under pressure — when things go wrong.

I always ask: “Walk me through your last scaling event.” If the answer is “We’ve never had one,” be skeptical. If it’s “We scaled once during launch,” ask for the details.

What you want to see: a system that **degrades gracefully** — it doesn’t crash, it adapts.

Green Light: Backpressure & Graceful Degradation

A strong event system handles **backpressure** — the ability to slow down or queue events when downstream systems are overwhelmed.

For example, during early-bird registration for a coin show, you might see a surge. A well-built system would:

• Rate-limit incoming API requests.
• Queue registration events with priority (e.g., VIPs first).
• Disable optional features (like raffle entries) while keeping core registration live.

During audits, I look for:

• Monitoring on queue length and processing latency.
• Auto-scaling for consumers (so they can catch up).
• Fallbacks (e.g., “Registration full, but here’s an estimated wait time”).

**What to do:** Request load test results — especially for event queues. If they can’t provide them? Assume the system won’t scale.

Code Quality: The Cost of “Set It and Forget It”

Event systems are easy to build. Hard to maintain. And when they go wrong, they go *really* wrong.

Common code-level issues I see:

• Events are “fire and forget” — no visibility.
• No correlation IDs — making it impossible to trace a user’s journey.
• Inconsistent error handling (some services retry, others don’t).

Red Flag: No Correlation ID = Debugging Hell

Without correlation IDs, tracing a single user issue across multiple services is like finding a needle in a stack of needles.

I once spent 12 hours debugging a **parking validation failure** because events weren’t linked. One user. One problem. One wasted day.

Good practice? Include a correlation ID in every event:


// ✅ GOOD: Correlation ID in event
{
"eventId": "evt-123",
"correlationId": "corr-456",
"type": "ParkingTicketValidated",
"data": { ... }
}


**What to do:** Check event headers. If correlation IDs are missing or inconsistent, it’s a sign of weak observability — and a risk to post-acquisition support.

Green Light: Testing Event Flows End-to-End

The best companies test event flows in CI/CD. Not just unit tests — full event chains.

For example:
– Emit a “RegistrationCompleted” event.
– Verify that “BadgePrinted” fires within 2 seconds.
– Confirm that “ParkingValidationSent” has the correct attendee ID.

This prevents regressions and keeps event contracts stable.

If they’re doing this? It’s a strong sign of engineering discipline.

Integration Risk: What Happens After the Deal

You’re not buying a product. You’re buying a system that needs to **work with yours**.

Ask:

• Does it use standard tools (Kafka, RabbitMQ, SQS)?
• Are event schemas documented and versioned?
• Is there vendor lock-in (e.g., a custom event broker)?

I’ve seen deals collapse because the target used a proprietary system. Migration would’ve cost $2M and taken 18 months.

That’s not innovation — it’s **technical debt masquerading as architecture**.

Red Flag: “It’s Just a Simple Script”

If a CTO says, “It’s just a simple script,” brace yourself.

I’ve audited “simple” scripts that were 500-line functions with no error handling, no logging, and no tests. They work — until they don’t.

**What to do:** Demand a **runbook** for every event consumer. If it doesn’t exist, assume it will fail during integration.

Event Architecture Is a Litmus Test for Tech Health

EDA isn’t just a pattern. It’s a window into a company’s engineering culture.

When you assess a target, don’t just look at the surface. Look at their events. Ask:

• Are events consistent and versioned?
• Can they trace a user’s journey?
• Does the system degrade gracefully under load?
• Will it survive integration with your stack?

If the answers are “no,” it’s not just a code problem. It’s a **deal risk**.

Remember: A green light isn’t “it works.” It’s **“it works, scales, and survives.”**

And in M&A, that’s the only kind you want.

Related Resources

You might also find these related articles helpful:

• How I Turned My Knowledge of Coin Shows into a $50,000 Online Course – I love teaching what I know — it’s how I turned my passion for coin shows into a $50,000 online course. No fancy s…
• How I Leveraged Niche Event Expertise to Command $200/Hr+ as a Tech Consultant – Want to know how I went from standard tech consulting gigs to charging $225/hour (and up)? It’s simple: I stopped trying…
• Optimizing Supply Chain Software: Technical Strategies for Smarter WMS, Fleet, and Inventory Systems – Efficiency in logistics software can save companies millions — I’ve seen it firsthand. Over the past decade as a logisti…