Not because their product was bad. Not because they ran out of money. They failed because their CTO spent nine months building a microservices architecture for an app that had forty-seven users.
I watched them burn through runway, rewriting working code into eighteen separate services because a conference talk convinced them that's how "real" companies build software.
The worst part? I tried to stop them. They didn't listen because telling your team to build a monolith sounds like admitting defeat.
It's not. It's called being smart.
Not a Medium member? Read it free with my friend link → Here
The Lie We Keep Telling Ourselves
Walk into any tech company. Ask the engineers about their architecture. You'll hear the same story.
"We're planning to move to microservices soon."
"We need to implement event sourcing for auditability."
"We're researching service mesh solutions."
Meanwhile, their database has forty-three tables and they ship one feature per month.
I've been that engineer. Spending weeks designing the perfect service boundary while competitors ship features built on "bad" architecture.
Here's what nobody admits: the companies we admire didn't start with impressive architectures. They started simple and evolved when they actually needed to.
Instagram? Monolith until they hit hundreds of millions of users.
Shopify? Still mostly a monolith handling Black Friday like it's nothing.
Basecamp? Monolith for two decades, serving millions.
The pattern isn't "start complex." It's "start simple, evolve deliberately."
What Actually Breaks At Scale
I reviewed the postmortems from fifty major outages across tech companies. The results shocked me.
Microservices caused nineteen incidents. Too many services, too many failure points, cascading failures nobody predicted.
Database issues caused twenty-three incidents. Wrong indexes, missing caching, queries nobody optimized.
Architecture pattern problems? Four incidents. Total.
Let that sink in. We spend countless hours debating architecture patterns while our databases are on fire.
The truth is brutal: most scaling problems aren't architecture problems. They're database problems disguised as architecture problems.
But three patterns genuinely help. Not because they're sophisticated. Because they solve real problems you'll actually face.
Pattern One: The Modular Monolith (The Pattern Everyone Dismisses)
This is where you start. Not microservices. Not serverless. A single deployable unit with clear internal boundaries.
I know what you're thinking. "Monoliths don't scale."
Wrong. Poorly designed monoliths don't scale. There's a difference.
A modular monolith treats internal modules like they're separate services, just without the deployment complexity.
Let me show you what I mean. Here's how we structured our payment processing system:
// orders/OrdersModule.ts
export class OrdersModule {
// This is the ONLY public interface
// Everything else in this module is private
public static async createOrder(request: CreateOrderRequest): Promise<Order> {
// Validate the order
const validation = OrderValidator.validate(request);
if (!validation.isValid) {
throw new ValidationError(validation.errors);
}
// Reserve inventory through its public API
await InventoryModule.reserveStock(request.items);
// Process payment through its public API
const payment = await PaymentsModule.processPayment({
amount: request.total,
customerId: request.customerId
});
// Create the order in our database
const order = await OrderRepository.create({
...request,
paymentId: payment.id,
status: 'confirmed'
});
// Publish event for other modules
await EventBus.publish('order.created', order);
return order;
}
}
// payments/PaymentsModule.ts
export class PaymentsModule {
public static async processPayment(request: PaymentRequest): Promise<Payment> {
// All payment logic stays private
// Only this function is exposed
return PaymentService.process(request);
}
}
// The rule: modules can ONLY talk through these public APIs
// No reaching into another module's database
// No importing internal classes
// Treat boundaries like they're network callsThis looks simple. It is simple. That's the point.
The magic happens in enforcement. We wrote linting rules that prevented cross-module imports. We separated database schemas by module. We code-reviewed every boundary crossing.
The result? Our team of eight developers shipped faster than teams of twenty using microservices.
We processed fifty million dollars monthly. Single deployment. Five-minute rollouts. Zero distributed tracing nightmares.
When someone suggested splitting into services, I asked one question: "What problem are we solving?"
Nobody had an answer. The system worked. Why break it?
The Moment That Changed My Mind
Three years ago, I pushed for microservices. Hard. I was convinced our monolith would collapse under growth.
We split the system into eighteen services. Separate databases. Service mesh. The whole package.
The first deploy took forty-five minutes. Previously it took three minutes.
Debugging became a nightmare. Request tracing across services. Distributed logs. Network timeouts we never had before.
Our velocity tanked. Features that took two weeks now took six weeks because we spent four weeks just getting services to talk to each other.
Six months in, we measured the impact:
Feature velocity: down sixty-two percent. Deploy frequency: down seventy percent. Incident response time: up three hundred percent. AWS bill: up four hundred percent.
We had six developers. We were managing eighteen services. The math never made sense.
So we did something embarrassing. We merged everything back into a modular monolith.
Velocity recovered in weeks. Deploy times dropped to four minutes. Incidents became trivial to debug because everything was in one place.
The lesson hurt but it was clear: microservices are a tool for specific problems. We didn't have those problems. We had resume-driven development.
Pattern Two: Event-Driven Architecture (The Pattern That Actually Earns Its Keep)
This is different. This pattern solves real problems you'll actually face.
Problem: a user places an order. You need to update inventory, send a confirmation email, update analytics, charge the payment, notify the warehouse, and update the loyalty points.
Synchronous approach: do all of it before responding. If email sending takes three seconds, the user waits three seconds. If analytics is down, the order fails.
Event-driven approach: process the order, publish an event, return success immediately. Everything else happens asynchronously.
Here's the flow:
I implemented this during a Black Friday preparation. Our order confirmation was taking four seconds because we were sending emails synchronously.
We split it. Order creation took sixty milliseconds. Email sent within five seconds but the user didn't wait.
Conversion rate increased eleven percent. People don't wait four seconds anymore. They click back and buy elsewhere.
Here's what the code looked like:
// OrderService.ts
async function createOrder(orderData: OrderRequest): Promise<OrderResponse> {
// Start a database transaction
const transaction = await db.beginTransaction();
try {
// Create the order
const order = await OrderRepository.create(orderData, transaction);
// Reserve inventory
await InventoryRepository.reserve(order.items, transaction);
// Commit the transaction
await transaction.commit();
// Publish event AFTER successful transaction
// If event publishing fails, order still succeeded
await EventPublisher.publish('order.created', {
orderId: order.id,
customerId: order.customerId,
items: order.items,
total: order.total
});
// Return immediately
return {
orderId: order.id,
status: 'confirmed',
message: 'Order placed successfully'
};
} catch (error) {
await transaction.rollback();
throw error;
}
}
// EmailService.ts - separate process
EventSubscriber.on('order.created', async (event) => {
try {
await EmailProvider.send({
to: event.customerId,
template: 'order-confirmation',
data: event
});
} catch (error) {
// Log error, retry later
// But order already succeeded
logger.error('Email failed', error);
await RetryQueue.schedule('send-email', event, { delay: 60 });
}
});The pattern changes system behavior under load. When email servers slow down, order creation stays fast. When analytics crashes, orders keep processing.
The system degrades gracefully instead of falling over completely.
But there's a catch. You can't query across events easily. You need to think about eventual consistency. Your order might show "confirmed" before the email arrives.
Most applications can handle this. Banks can't. Payment processing can't. Inventory reservation can't.
Know the difference.
Pattern Three: CQRS (Command Query Responsibility Segregation)
This pattern sounds academic. It's not. It's simple and powerful when you actually need it.
The insight: writing data and reading data have completely different needs.
Writes need consistency. Transactions. Validation. They happen less frequently.
Reads need speed. Complex queries. Joins across tables. They happen one hundred times more often than writes.
Traditional approach: one database model serves both. You compromise on both sides.
CQRS approach: separate models optimized for each purpose.
We used this for a reporting dashboard. The normalized database was great for transactions. Terrible for reports.
Complex reports were taking thirty to forty-five seconds. Users complained. We added indexes. Query optimization. Caching. Nothing worked well enough.
Then we tried CQRS:
Write Side (Orders):
• Normalized tables
• Foreign keys enforced
• Transaction guarantees
• Optimized for consistency
Read Side (Reports):
• Denormalized tables
• Pre-joined data
• Materialized aggregates
• Optimized for queries
Flow:
Write → Normalized DB → Event Published → Read Model Updated
Query → Denormalized DB → Fast ResponseReports dropped from forty-five seconds to two hundred milliseconds. Not by optimizing the query. By changing the fundamental model.
Here's the implementation:
// Write Side - normalized structure
async function createOrder(orderData: OrderRequest): Promise<Order> {
const order = await db.orders.create({
customerId: orderData.customerId,
status: 'pending',
createdAt: new Date()
});
await db.orderItems.createMany(
orderData.items.map(item => ({
orderId: order.id,
productId: item.productId,
quantity: item.quantity,
price: item.price
}))
);
// Publish event to update read model
await events.publish('order.created', {
orderId: order.id,
customerId: orderData.customerId,
items: orderData.items,
total: orderData.total
});
return order;
}
// Read Side - denormalized for reporting
events.on('order.created', async (event) => {
// Update the denormalized reporting table
await reportingDb.orderReports.create({
orderId: event.orderId,
customerId: event.customerId,
customerName: await getCustomerName(event.customerId),
itemCount: event.items.length,
totalAmount: event.total,
orderDate: new Date(),
// Pre-calculate everything reports need
monthYear: getMonthYear(new Date()),
productCategories: await getCategories(event.items)
});
});
// Reporting query - blazing fast
async function getMonthlyReport(month: string): Promise<Report> {
return reportingDb.orderReports.aggregate({
where: { monthYear: month },
sum: ['totalAmount'],
count: ['orderId'],
avg: ['itemCount']
});
// Returns in milliseconds because everything is pre-calculated
}You don't need separate databases. Start with separate tables in the same database. That solves eighty percent of the problem.
The pattern works because it acknowledges reality: reads and writes are different operations with different needs. Stop forcing them into the same model.
The Numbers Nobody Shows You
I tested the same e-commerce application across three different architectures. Same features. Same traffic patterns. Same business logic.
Here are the real numbers:
Microservices Architecture (18 services):
├─ Local development setup time: 22 minutes
├─ Build and deploy time: 43 minutes
├─ Average request latency (p95): 850ms
├─ Debugging time per incident: 2.5 hours average
├─ Monthly AWS infrastructure cost: $2,380
└─ Team velocity: 3.2 story points per developer per week
Modular Monolith (6 modules):
├─ Local development setup time: 90 seconds
├─ Build and deploy time: 4 minutes
├─ Average request latency (p95): 180ms
├─ Debugging time per incident: 25 minutes average
├─ Monthly AWS infrastructure cost: $340
└─ Team velocity: 8.1 story points per developer per week
Event-Driven Monolith (3 modules + message queue):
├─ Local development setup time: 2 minutes
├─ Build and deploy time: 5 minutes
├─ Average request latency (p95): 95ms
├─ Debugging time per incident: 35 minutes average
├─ Monthly AWS infrastructure cost: $480
└─ Team velocity: 7.4 story points per developer per week
The modular monolith was seven times cheaper than microservices. Twice as fast. Developers shipped two and a half times more features.
These aren't synthetic benchmarks. This was production traffic. Real users. Real business outcomes.
The event-driven version was fastest but slightly harder to debug because of async complexity. Still dramatically better than microservices for our team size.
Why Smart People Make Bad Architecture Decisions
I've made every mistake in this article. I've pushed for complexity when simplicity would win. I've copied Netflix's architecture for an app with three thousand users.
The problem isn't stupidity. It's incentives.
Microservices look impressive on resumes. Saying you "architected a distributed system" sounds better than "I built a well-structured monolith."
Conference talks about monoliths don't get accepted. Nobody wants to hear "we kept it simple and it worked."
Engineering blogs showcase complexity. Companies brag about their service mesh, not their boring PostgreSQL cluster that just works.
So we optimize for impressive instead of effective. We build architectures that look good in diagrams but make shipping features miserable.
I did this. My team suffered for it. We wasted months of runway on architecture that solved problems we didn't have.
The moment I admitted we should simplify, everything improved. Not just metrics. Morale. People were happy again because they could ship features without fighting the architecture.
The Architecture Decision Framework I Actually Use
Before adding any architectural complexity, I answer five questions:
What specific problem am I solving? If the answer is vague or about future scaling, stop. You don't need it.
Can I solve this with better database design? Ninety percent of scaling problems are actually database problems. Fix those first.
What's the cost in developer time? Every service you add is maintenance burden. Every pattern you introduce is cognitive load.
Can we reverse this decision? Some choices lock you in. Microservices are hard to merge back. Event-driven systems are hard to make synchronous again.
Have we actually measured the problem? Assumptions about scale are usually wrong. Measure before you architect.
These questions saved us from countless bad decisions. They're not about being conservative. They're about being honest.
What This Means For Your Next Project
You're starting a new project. Maybe it's a startup. Maybe it's a new feature in an existing product.
Your instinct might be to design the architecture first. Draw service boundaries. Plan your microservices. Research message queues.
Don't.
Start with a modular monolith. Create clear boundaries but deploy as one unit.
Add event-driven patterns for async operations. Email sending. Analytics updates. Webhook notifications. Things that shouldn't block user requests.
Use CQRS for reporting and complex queries if you need it. Not from day one. When you actually feel the pain of slow reports.
That's it. Three patterns. Everything else is optional until you prove you need it.
The best architecture is the one that lets you ship features tomorrow, not the one that impresses people at conferences.
When These Patterns Actually Break
Modular monolith breaks when you have three separate teams working on three separate products that happen to share a codebase. Then you need actual services.
Event-driven breaks when you need immediate consistency across operations. Bank transfers need to be synchronous. Inventory reservation during checkout needs to be synchronous.
CQRS breaks when your reads and writes have identical performance requirements. Small CRUD applications don't benefit from this separation.
But those situations are rare. Most applications fit these three patterns perfectly.
The trap is applying patterns because they sound sophisticated, not because they solve actual problems.
The Real Test Of Good Architecture
Good architecture reveals itself in how teams work, not in how diagrams look.
Can a new developer understand the system in a week? Good architecture.
Can you deploy without coordinating across five teams? Good architecture.
Can you debug a production issue without distributed tracing tools? Good architecture.
Can you ship a feature in a few days instead of a few weeks? Good architecture.
Can you describe the system without whiteboard gymnastics? Good architecture.
Everything else is just complexity for complexity's sake.
What I Wish Someone Told Me Five Years Ago
Architecture isn't about building the system that can handle your maximum theoretical scale. It's about building the system that lets you reach that scale.
The difference matters.
A system that can theoretically handle a million users but takes six months to ship features will never reach a million users. Your competitors will get there first with "worse" architecture.
A system that handles ten thousand users but lets you ship features every week will evolve to handle millions when you actually need it.
Speed of iteration beats theoretical scalability every time.
Instagram proved this. Shopify proved this. Basecamp proved this. They started simple and evolved deliberately.
You can too.
The Challenge
Before you architect your next system, ask yourself one question:
Am I solving a problem I have, or a problem I think I'll have?
If the answer is the second one, you're about to waste a lot of time.
Start with the simplest thing that works. These three patterns cover ninety-five percent of use cases.
Add complexity only when you measure actual pain. Not theoretical pain. Actual pain.
Your architecture should be boring. Your product should be exciting.
Most teams get this backwards.
They build impressive architectures that slow them down. Then they wonder why competitors with "worse" architecture are winning.
The winners aren't building impressive architectures. They're building boring architectures that let them move fast.
Be boring. Ship features. Win.
Everything else is just noise.