Decision Simulator

At month 4, the team is 30% of the way through. The monolith keeps receiving new features because the business can’t wait. Now you have two systems to maintain and the team is split. The CTO starts asking when it will be ready.

Lesson: Complete rewrites almost never finish on time. The business doesn’t stop while you rewrite.

At month 3, you extracted the notifications service. The monolith’s deploys are a bit faster. The team learned about inter-service communication, service discovery, and distributed monitoring. Now you can plan the next extraction with more confidence.

Lesson: The Strangler Fig pattern lets you migrate gradually with controlled risk. Each extraction teaches lessons for the next one.

At month 2, the monolith is organized into modules with clear interfaces. Merge conflicts dropped by 60%. Deploys still take 45 minutes, but now you can do partial deploys per module. The team has a solid foundation to extract services in the future if needed.

Lesson: Sometimes the best distributed architecture is the one you don’t need. A well-organized monolith can scale further than you think.

PostgreSQL handles the 500K rows and complex queries well. At month 6, reads start to saturate the database. You add a read replica and the problem is solved. You implement the change history with an audit table and triggers.

Lesson: PostgreSQL is a solid choice for most cases. Don’t underestimate how far a well-configured relational database can go.

MongoDB works well at first. At month 3, you discover that aggregation queries with multiple filters are slower than expected. The flexible schema caused data inconsistencies because different parts of the team stored documents with slightly different structures.

Lesson: Schema flexibility is a double-edged sword. Without discipline, it creates technical debt. MongoDB shines when the data model is genuinely hierarchical.

The combination works very well for reads. But at month 2, you discover cache invalidation bugs: some users see stale data after updates. You implement an event-based invalidation system and the problem is solved, but operational complexity increased significantly.

Lesson: Adding a cache solves performance problems but introduces consistency problems. Only add a cache when you truly need it, not “just in case.”

It works, but reconciliation across two providers is complex. Some payments are processed on Stripe and others on PayPal, which complicates financial reporting. On top of that, PayPal has its own failure rate — it’s not immune. At month 3, you have a more resilient system but one that’s significantly more complex to operate.

Lesson: Multiple providers increase availability but multiply complexity. Weigh whether the operational cost justifies the improvement in availability.

Automatic retries resolve 90% of transient failures. But you discover a problem: some payments are processed twice because the retry arrives when Stripe had already processed the first one (but responded with a timeout). You implement idempotency with unique keys and the problem is solved.

Lesson: Retries without idempotency are dangerous. Always implement idempotency before implementing automatic retries.

The circuit breaker detects failures within seconds and stops sending requests to Stripe. Users see a clear message: “The payment system is temporarily unavailable. Your cart is saved — you can complete the purchase later.” The experience isn’t perfect, but it’s honest and doesn’t create frustration.

Lesson: Sometimes the best response to a failure is to be transparent with the user. Not every problem requires a complex technical solution.