DEV Community: Deepak Kumar Jha

Stop Polling, Start Reacting: Why Event-Driven Architecture Is Your Competitive Advantage

Deepak Kumar Jha — Sat, 01 Aug 2026 13:44:55 +0000

Stop Polling, Start Reacting: Why Event-Driven Architecture Is Your Competitive Advantage

There's a pattern I see in almost every backend I'm asked to review: polling. The order service checks the payment service every 5 seconds: "Has the payment been confirmed?" The notification service queries the database every 10 seconds: "Are there new events?" The analytics dashboard refreshes every 30 seconds: "Is there new data?"

Each individual polling call is cheap. But multiply it across every service, every user, every second — and you're generating millions of unnecessary requests per day. Your database is spending more time answering "no, nothing has changed" than doing actual work.

This is the problem Event-Driven Architecture solves.

What Event-Driven Architecture Actually Means

The concept is simple. Instead of services constantly asking each other "did anything happen?", each service announces when something happens, and other services listen for announcements they care about.

When a user places an order, the Order Service publishes an event: Order Created. The Payment Service hears this and processes the payment. When payment succeeds, it publishes: Payment Confirmed. The Inventory Service reserves the stock. The Notification Service sends the confirmation email. The Analytics Service updates the dashboard.

No service is asking anyone anything. No service needs to know which other services exist. Each service does its job and announces the result.

Why This Matters for Your Business

Speed to Market

In a polling-based system, adding "send an SMS when a payment fails" requires modifying the payment service to call the SMS service. In an event-driven system, you build a new SMS service that listens for Payment Failed events. The payment service doesn't change at all.

I've seen this pattern reduce the time to add new integrations from 2-3 weeks to 2-3 days.

Resilience and Fault Tolerance

If the notification service goes down in a synchronous architecture, the order might fail. In an event-driven architecture, if the notification service goes down, the events wait in the message queue. When it comes back online, it processes the backlog. The user's order was never affected.

Horizontal Scaling

If your order volume doubles, you add more consumer instances. The event broker distributes the load automatically. I've seen this support a 10x traffic increase with minimal infrastructure changes.

Choosing the Right Event Backbone

For Most Startups (under 10,000 events/second): Managed message queues — AWS SQS with SNS, Google Cloud Pub/Sub, or Azure Service Bus. Fully managed, no infrastructure to maintain.

For High-Throughput Requirements: Apache Kafka excels when you need massive throughput (100,000+ events/second), event replay, long-term storage, and stream processing. Always use managed Kafka services (AWS MSK, Confluent Cloud) unless you have a dedicated platform engineering team.

The Hybrid Approach: Use Kafka for critical business events requiring durability and ordering. Use simpler queues (SQS/RabbitMQ) for lightweight operational events like notifications and logging.

Common Pitfalls

Event Spaghetti: Maintain a central event registry with schemas, producers, and consumers documented. Treat event schemas like API contracts — version them and never make breaking changes without migration support.

Eventual Consistency Confusion: Operations requiring immediate consistency (e.g., deducting a balance) should happen within a single service. Only the result (the event) is published asynchronously.

Lost Events: Configure your broker for at-least-once delivery. Design your consumers to be idempotent — processing the same event twice produces the same result as once.

Getting Started: The Incremental Approach

Step 1: Identify the highest-volume polling pattern in your current system. Convert it to event-based communication using a simple message queue. Measure the reduction in database load.
Step 2: Identify the integration point causing the most deployment friction. Introduce events at this boundary.
Step 3: As you extract services, make event-driven communication the default for inter-service communication.

Originally published on LinkedIn

The Real Cost of Quick Fixes: How Technical Shortcuts Become Business Debt

Deepak Kumar Jha — Sat, 01 Aug 2026 13:38:26 +0000

The Real Cost of "Quick Fixes": How Technical Shortcuts Become Business Debt

A founder recently told me: "Our developers keep saying we have 'technical debt' and need to stop building features to fix it. But we have a product launch next quarter. I can't afford to stop."

I told him: "You're not hearing a technical request. You're hearing a risk warning. And every month you ignore it, the risk compounds."

The problem isn't technical debt itself. It's that nobody is translating it into the language the business actually uses: risk, cost, and velocity.

What Technical Debt Actually Costs (In Business Terms)

It Slows Down Feature Delivery

In a codebase with high technical debt, feature delivery velocity is typically 2-4x slower than in a comparable clean codebase. That means your competitor — with the same team size and the same feature ideas — ships 2-4 times faster than you. Not because they have better engineers. Because their engineers aren't fighting the codebase.

It Increases Incident Frequency and Severity

In one client's platform, a "quick fix" from two years ago had introduced a race condition in the checkout flow. Under normal traffic, it was invisible. During a promotional event that tripled traffic, the race condition triggered for approximately 2% of transactions — resulting in double charges.

The incident took 14 hours to diagnose and fix. Quick fixes create hidden failure modes that surface at the worst possible time — during peak traffic, during a product launch, during a fundraising demo.

It Makes Hiring Harder (and More Expensive)

Strong senior engineers can assess a codebase within the first week. If they see extensive tech debt, many will leave during the probation period. One company I worked with hired 5 senior backend developers — three left within 3 months citing "unmaintainable codebase." The cost of recruiting, onboarding, and losing those three engineers exceeded $100,000.

It Blocks Strategic Initiatives

Want to add AI features? Your data layer may be too tangled to feed structured data into a RAG pipeline.
Want to expand to a new market? Your auth logic scattered across 15 files makes compliance changes a minefield.
Want to raise a Series B? Technical due diligence will assess your codebase — significant technical debt directly reduces your valuation.

The Framework: Translating Debt into Business Risk

When I work with leadership teams, I present technical debt in a format they can evaluate alongside other business risks:

Velocity Drag: "Our current tech debt is reducing feature delivery speed by an estimated 40%. The 6 features planned for Q2 will likely take until Q3. If we invest 4 weeks in targeted debt reduction now, we recover most of that velocity."

Incident Probability: "We have 3 known areas of fragile code in the payment and user authentication flows. Based on the last 6 months, there's a meaningful likelihood of a production incident. The estimated cost ranges from $15,000 to $50,000 depending on severity."

Hiring and Retention Risk: "Our last 2 senior hires cited codebase quality as a concern during exit interviews. We're spending roughly $25,000 per senior hire in recruitment costs. If codebase quality continues to be a retention issue, we're likely to see $50,000-100,000 in annual recruitment waste."

The Pragmatic Approach: The 20% Rule

I don't advocate for "tech debt sprints" where the team stops building features. Instead, I implement the 20% Rule: every sprint, 20% of engineering capacity is allocated to debt reduction. This is not negotiable and not deferred when deadlines are tight.

How it works:

Prioritize by business impact, not engineering preference
Attach debt reduction to feature work — when building a new feature in a high-debt area, clean up that area alongside the feature
Track the results — measure feature delivery time, incident frequency, and deployment frequency before and after
Make it visible — every debt work item has a ticket, every ticket has a business justification

Over 6-12 months, this steady approach produces a dramatically healthier codebase without ever requiring a "feature freeze."

Originally published on LinkedIn

Why I Stopped Charging Hourly and Started Charging Per Milestone — And Why My Clients Prefer It

Deepak Kumar Jha — Sat, 01 Aug 2026 13:38:17 +0000

Why I Stopped Charging Hourly and Started Charging Per Milestone — And Why My Clients Prefer It

Three years ago, I was working with a startup founder in New York. We were eight weeks into a backend architecture project, billed hourly. Every two weeks, the same uncomfortable conversation happened: "Deepak, can you explain why this took 47 hours? I expected it to take around 30."

The problem wasn't dishonesty or poor estimation. The problem was structural. Hourly billing puts the client and the contractor in adversarial positions — the client wants fewer hours, the contractor has no incentive to be faster. Every invoice becomes a negotiation.

After that project, I restructured my entire engagement model. I stopped billing hourly and moved to milestone-based pricing. The result was transformative — for my clients and for me.

The Problem with Hourly Billing (From Both Sides)

The Client's Perspective: When you hire a contractor at $100-200 per hour, every hour feels like a meter running. This creates exactly the wrong dynamic for senior technical work. Architecture decisions, system design, debugging complex production issues — these require deep thinking, exploration of options, and sometimes deliberate pauses to ensure the right approach.

The Contractor's Perspective: Hourly billing punishes efficiency. If I solve a problem in 2 hours that another developer would take 20 hours to solve, I earn 10% of what a less experienced developer would earn for the same outcome. My 12+ years of experience actually reduces my income.

The Trust Problem: The fundamental issue is misaligned incentives. Hourly billing means the contractor earns more when things take longer. The client knows this. Even if the contractor is completely honest, the suspicion is always there.

How Milestone-Based Pricing Works

Phase 1: Discovery and Scope (Paid, Fixed Price)

Before any major project begins, I conduct a paid discovery phase (typically 1-2 weeks). This results in a detailed scope document including: business objectives and success criteria, technical architecture overview, a milestone breakdown with clear deliverables, a fixed price for each milestone, and acceptance criteria definition.

Phase 2: Milestone Execution

The project is divided into 3-7 milestones, each representing a functional deliverable. Not "backend work for 3 weeks" — but "User authentication system deployed and tested, supporting email/password, OAuth, and role-based access control."

Each milestone has a fixed price. Payment is made when the milestone is delivered and accepted. This aligns incentives correctly: I'm rewarded for being efficient and experienced, not for being slow. The client pays for outcomes, not hours.

Phase 3: Change Management

If the client wants to add scope within an existing milestone, we discuss the impact and either adjust the milestone price or create a new milestone. Projects always evolve — milestone pricing handles this cleanly.

How I Price Milestones

I price based on three factors:

Value to the client. A user authentication system that unlocks subscriptions is worth more than a logging improvement.
Complexity and risk. Milestones involving third-party integrations or data migrations carry more risk; the price includes a buffer.
My expertise and efficiency. If I can deliver faster because I've built similar systems before, the savings are mine to keep.

In practice, my effective hourly rate under milestone pricing is 30-50% higher than under hourly billing. And my clients' total project cost is typically comparable or lower — because upfront scoping prevents scope creep.

Why International Clients Prefer This Model

No time zone accounting — clients evaluate deliverables, not timesheets
Clear progress visibility — each milestone is a visible, testable deliverable
Predictable budget — total cost is known from the beginning, no surprise invoices
Quality alignment — I'm paid per deliverable, so I have every incentive to build it well the first time

One client in London told me directly: "I always felt like I was managing their time more than managing the project. With you, I just review milestones. It's a completely different experience."

Originally published on LinkedIn