SaaS shared database and coupled releases
A B2B SaaS company has 40 engineers and three product lines: billing, analytics, and workflow. All three share one PostgreSQL database and one schema. Releases are coupled: a billing migration caused a four-hour outage that affected analytics customers. Engineers spend 22% of sprint capacity on cross-team coordination and dependency meetings. The CTO proposes microservices, starting with a six-month re-platforming program. The VP of Engineering wants three independent product teams, each owning its data and roadmap. Sales insists on one shared roadmap and quarterly feature commitments across all lines. Customer escalations rose 30% after the outage; two enterprise prospects delayed signing. The company has no platform team and no API versioning standard. A recent architecture review found 14 shared tables used by all three products. The board wants a recommendation before the next quarter. The CTO's program has no product funding, only infrastructure funding.
1. Is the CTO's microservices program the right first move? Diagnose the relationship between the shared database, release coupling, and organizational structure.
Read the worked answer
Microservices may be a later step, but the first move is to establish boundaries and ownership. Fourteen shared tables and one schema create release coupling: a billing migration caused an analytics outage because all products share one deployable data model. With three product lines but one data boundary and no platform team, the architecture contradicts the intended organization; this is a Conway mismatch. A six-month microservices program without domain boundaries would distribute the coupling and add operational overhead. First, map bounded contexts, assign each shared table to one owning product, introduce schema-per-domain, and define API contracts for cross-domain reads. Then extract services only where transaction boundaries and team ownership justify the cost. The CTO's program is also funded as infrastructure, not product, so it lacks customer outcomes and adoption measures. Recommend discovery and a strangler sequence, not a big-bang re-platforming.
2. Propose a sequencing plan for the next two quarters that reduces coupling without a big-bang rewrite. Include one guardrail.
Read the worked answer
Quarter one: map data ownership for billing, analytics, and workflow; assign all 14 shared tables to a single owning product; introduce schema-per-domain and views or APIs for cross-domain access; freeze new cross-domain joins. Form three product teams and a small platform team for continuous delivery, observability, and an API gateway. Quarter two: extract one high-pain capability, such as billing invoicing, behind an API using a strangler approach; move analytics to events or read models; add API versioning and deprecation policy. Guardrail: no service extraction without a named owning team, an SLO, and a rollback plan. Measure cross-team dependency count, lead time, change failure rate, and outage blast radius. This sequence reduces coupling and proves the operating model before scaling microservices. It also gives sales evidence of delivery stability, which matters after the outage and delayed prospects.
3. Sales wants one shared roadmap with quarterly feature commitments. How should engineering respond without losing the enterprise prospects?
Read the worked answer
Separate internal team autonomy from external commercial commitment. Sales can have one portfolio roadmap with quarterly outcome commitments, not one shared feature backlog. Engineering should publish a capacity and dependency model: what each product line can commit to, what depends on platform work, and what is still in discovery. Offer prospects outcome-based roadmap commitments, service levels, and a named product contact. Internally, keep three product backlogs with a portfolio review for cross-line dependencies. Use confidence labels: committed, likely, exploratory. This preserves sales credibility without recreating the coupling that caused the outage. If two prospects need the same integration, treat it as a platform service with a product manager and its own roadmap. Measure on-time outcome delivery, escalation rate, and dependency count. Do not let quarterly feature promises override the boundary work; negotiate scope by outcome and sequence.