Conway's Law and Team Topology

Conway's law in practice

Melvin Conway observed (1968) that organizations produce designs that copy their communication structures. If ledger and fraud teams talk daily through a shared Slack channel, their services will merge logic informally. If they interact only via quarterly API reviews, boundaries stay strict — but integrations become brittle without investment.

ShardPay's pre-2023 structure had one "Payments Backend" team owning gateway, ledger, fraud, and notifications as a modular monolith. Deploys were weekly and coordinated. Conway predicted: the architecture was a monolith because the team was one unit.

Post-restructure, four stream-aligned teams emerged. Within 6 months, the monolith split along the same seams the teams already owned informally — not because leadership drew microservice boxes, but because ownership drove extraction.

Team Topologies at ShardPay

Team Topologies (Skelton & Pais) defines four team types. ShardPay maps cleanly — with one enabling team for security compliance coaching.

Stream-aligned teams

Each team has on-call rotation for their services, own error budget, and deploy independently via platform pipelines.

Platform team

Provides Golden Path templates: Spring Boot starter with OTel, Resilience4j, idempotency middleware pre-configured. Stream teams adopt voluntarily — forced adoption failed in 2022; voluntary Golden Path succeeded at 95% uptake by 2025.

Enabling team

Security and compliance coaches — not permanent owners. They run 6-week engagements helping ledger team implement PCI audit requirements, then exit. Permanent ownership stays with stream team.

// ShardPay Golden Path starter — platform team ships, stream teams consume
@AutoConfiguration
public class ShardPayPlatformDefaults {
    @Bean
    public OtlpGrpcSpanExporter otelExporter(PlatformConfig config) {
        return OtlpGrpcSpanExporter.builder()
            .setEndpoint(config.otelEndpoint())
            .build();
    }
    @Bean
    public IdempotencyFilter idempotencyFilter(IdempotencyStore store) {
        return new IdempotencyFilter(store, Duration.ofHours(24));
    }
}

Aligning boundaries with communication

Conway is a constraint, not an excuse. Use it to decide where services split and where teams merge.

Walkthrough: should fraud scoring merge into ledger?

Proposal: embed fraud checks inside ledger service to reduce latency.

Conway analysis: fraud team and ledger team have different release cadences (fraud deploys daily for rule updates; ledger deploys weekly with extra review). Different skills (ML engineers vs database engineers). Communication is API-contract-level, not pair-programming.

Decision: keep separate services. Accept 8ms network hop. Invest in contract tests and shared trace context instead of merging teams or services.

Outcome: fraud team shipped new ML model without ledger deploy — 94ms → 61ms fraud latency improvement independent of ledger release cycle.