Chapter 14 Flashcards — Service-Based Architecture Style
flashcards fsa service-based-architecture
What is service-based architecture and where does it sit on the architecture spectrum?
?
Service-based architecture is a distributed style with a small number of coarse-grained, domain-scoped services (typically 4–12) sharing a common database layer, accessed by a UI via an optional API gateway. It sits between a monolith and microservices — delivering most of microservices’ agility at far less operational complexity. It is the most pragmatic distributed architecture style.
What is the defining characteristic that distinguishes service-based architecture from microservices?
?
Granularity. In service-based architecture, services are coarse-grained (domain-scoped — one service owns all business logic for an entire business domain, e.g., “Order Management”). In microservices, services are fine-grained (subdomain/function-scoped, e.g., “Order Placement”, “Order History”, “Order Cancellation” are separate services). Service-based has 4–12 services; microservices has dozens to hundreds.
Why is the 4–12 service count considered the sweet spot for service-based architecture?
?
The 4–12 range maximizes agility vs. complexity: with 4–12 services, you get meaningful team autonomy (each team owns 1–3 services independently) without the operational overhead of managing dozens or hundreds of deployable units. Fewer than 4 services is effectively a modular monolith; more than ~20 begins approaching microservices complexity without the supporting infrastructure.
What are the three user interface options in service-based architecture and their trade-offs?
?
(1) Monolithic SPA: one frontend app talks to all services via API gateway — simplest, but creates a UI team bottleneck. (2) Modular UI: single app split into domain-aligned modules, each owned by its service team — good balance of simplicity and autonomy. (3) Micro-frontend: each service team owns their domain’s UI fragment, composed at runtime (module federation, web components) — maximum team autonomy but complex runtime composition.
What is the role of the API gateway in service-based architecture and is it required?
?
The API gateway is optional but commonly used. It handles cross-cutting concerns: authentication/authorization, rate limiting, request routing, SSL termination, request/response transformation, and logging. Placing these concerns in the gateway prevents each service from reimplementing them. The gateway routes UI requests to the appropriate domain service. Managed options include AWS API Gateway, Azure API Management, and Kong.
What is the shared monolithic database data topology and what is its main risk?
?
The shared monolithic database topology is a single database instance accessed by all services — the simplest starting point. Its main risk is schema coupling: changing a table impacts all services that depend on it, requiring cross-team coordination. The database becomes a hidden coupling point that negates service independence. It also creates a single point of failure for data and becomes a performance bottleneck at scale.
What is the domain-partitioned database topology in service-based architecture?
?
In the domain-partitioned topology, a single database instance contains separate schemas — one per service. Each service owns its schema and can evolve its tables independently without impacting other services. Cross-service queries require either API calls between services or read replicas. This reduces schema coupling while keeping operational simplicity (one DB instance to manage). It is the common intermediate step when maturing beyond a fully shared database.
What is the dedicated service database topology and what are its pros and cons?
?
In the dedicated service database topology, each service has its own database instance (potentially different technologies — polyglot persistence). Pros: maximum isolation; independent scaling; no schema coupling; services can choose the best DB technology per domain (Postgres, MongoDB, Redis, etc.). Cons: cross-service queries require API calls or event-driven replication; distributed transactions become necessary; highest operational complexity; data duplication risk.
What is the data topology progression from simplest to most isolated in service-based architecture?
?
Four steps: (1) Shared monolithic database — one DB, all services access everything (simple, tight coupling); (2) Domain-partitioned database — one DB instance, separate schemas per service (schema isolation, one DB to operate); (3) Dedicated service database — separate DB instance per service (maximum isolation, polyglot persistence); (4) Read replicas/materialized views — used alongside any topology for reporting/aggregation without coupling operational databases.
What are shared libraries in service-based architecture, and what is their governance risk?
?
Shared libraries package common code (database entities, auth helpers, utility functions) used by multiple services. The governance risk is versioning discipline: if a library change modifies a database entity schema, all dependent services must be updated and redeployed in coordination — recreating the tight coupling the style is trying to avoid. This is a step toward a distributed monolith. Mitigation: strict semantic versioning; major (breaking) library changes require a coordinated migration plan.
What is the Distributed Monolith antipattern in service-based architecture?
?
A distributed monolith occurs when services are nominally independent but have so many runtime dependencies (long synchronous call chains, shared DB tables read by all services, shared libraries that change together) that they must be deployed simultaneously. This is the worst outcome — all the complexity of distributed systems (network failures, latency, partial failures) with none of the independence benefits. Prevention: enforce schema ownership, minimize synchronous inter-service calls, use contract tests to verify independent deployability.
What is database coupling (shared database bottleneck) and how do you mitigate it?
?
Database coupling occurs when all services share one database schema, making schema changes a cross-team coordination event. Teams fear changing shared tables because they don’t know what will break. The database becomes a bottleneck for both team agility and runtime performance. Mitigation: enforce schema ownership (each table has one owning service); use domain-partitioned schemas to create schema boundaries; progress to dedicated databases as the system matures.
What is service granularity drift and what are its two failure modes?
?
Service granularity drift is when services gradually migrate away from the target 4–12 service count. Two failure modes: (1) Too fine: services keep splitting (single-responsibility pressure), eventually reaching microservices granularity without the microservices infrastructure — microservices complexity with monolithic-DB coupling. (2) Too coarse: only 2–3 very large services become mini-monoliths — independently deployable but internally difficult to work with. Mitigation: explicit service count targets; architecture review required before adding a service.
Compare service-based architecture vs. microservices on five key dimensions.
?
| Dimension | Service-Based | Microservices |
|---|---|---|
| Service count | 4–12 | Dozens–hundreds |
| Granularity | Domain (coarse) | Function (fine) |
| Data isolation | Optional (shared DB ok) | Required (per-service DB) |
| Operational complexity | Low–moderate | High |
| Scalability granularity | Per-service | Per-function |
Service-based is the pragmatic choice when microservices’ scalability granularity is not required.
Compare service-based architecture vs. monolith on team autonomy and deployment.
?
Monolith: all teams work in one codebase — merge conflicts, shared release trains, one deployment that affects everyone. Service-based: each service team owns their codebase, pipeline, and deployment schedule — independent deployments with no coordination needed. A service team can plan, build, test, and deploy their service without waiting for or impacting any other team. This independent deployability is the primary value proposition over a monolith.
What are the overall agility and ease of deployment ratings for service-based architecture?
?
Both receive ★★★★☆. Overall agility: independent service deployment enables fast per-domain iteration; shared database is the main drag (schema coupling reduces team autonomy). Ease of deployment: each service deploys independently with its own pipeline; far fewer deployment units than microservices (4–12 vs. dozens–hundreds) makes deployment pipelines manageable. Much simpler than microservices, much more agile than a monolith.
What are the testability, performance, and scalability ratings and their rationale?
?
All receive ★★★★☆. Testability: services tested independently; integration testing involves only the services under test + their API gateway contract; simpler than microservices because fewer services. Performance: coarse-grained services reduce inter-service network hops vs. microservices; shared DB provides fast in-database joins; acceptable for most workloads. Scalability: services scaled independently (horizontal scaling per service); coarser than microservices but far better than monolith.
What does cloud deployment look like for service-based architecture?
?
Each service runs as independently containerized deployments (Docker/Kubernetes); services scale horizontally per domain. A managed API gateway (AWS API Gateway, Azure API Management, Kong) handles routing and cross-cutting concerns. Managed databases (RDS, Aurora, Cosmos DB) reduce operational overhead for per-service databases. Each service has its own CI/CD pipeline for truly independent deployment. Secrets management (Secrets Manager, Key Vault) handles service credentials.
What are read replicas and materialized views used for in service-based data architecture?
?
Read replicas and materialized views enable cross-service reporting and analytics without coupling operational service databases. A reporting service queries a read replica (populated via change data capture from source service DBs) rather than the operational databases — no performance impact on services, no schema coupling. Materialized views pre-aggregate cross-domain data for dashboards and reports. This pattern is especially important when services have dedicated databases (no shared DB for joins).
When should you choose service-based architecture over a monolith?
?
Choose service-based over a monolith when: (1) team size has grown large enough that one codebase creates merge conflicts and deployment bottlenecks; (2) different domains evolve at different rates and need independent deployment; (3) domain-aligned teams already exist with clear ownership boundaries; (4) moderate independent scalability is needed (some services need more resources than others); (5) the organization needs more agility than a monolith provides but lacks the operational maturity for microservices.
When should you choose service-based architecture over microservices?
?
Choose service-based over microservices when: (1) extreme fine-grained scalability is not required — service-level (not function-level) scaling is sufficient; (2) the organization lacks microservices operational maturity (service mesh, distributed tracing, per-service databases, sophisticated orchestration); (3) cost is a concern — fewer services = less infrastructure, simpler monitoring, lower managed service bills; (4) development speed matters more than maximum scalability; (5) the system has a natural 4–12 domain boundary that doesn’t need further decomposition.
What is the e-commerce platform as a canonical service-based architecture example?
?
A classic service-based e-commerce system uses 6 services: User Management (auth, profiles), Product Catalog (SKUs, search, categories), Order Management (cart, checkout, order lifecycle), Inventory (stock, reservations), Payment (processing, refunds), Notification (email, SMS). Each is independently deployable, owned by a dedicated team, and initially shares a relational database partitioned by domain schema. An API gateway routes web and mobile traffic and handles authentication.
What is consumer-driven contract testing and why is it important in service-based architecture?
?
Consumer-driven contract testing (e.g., using Pact) is a testing approach where API consumers define their expectations of a service’s API, and those expectations become tests the service provider must satisfy. It is important in service-based architecture because it verifies that services remain independently deployable — a provider can safely deploy a new version if all consumer contracts still pass. Without contract testing, integration failures are discovered only in shared integration environments, slowing down independent deployment.
What is BFF (Backend for Frontend) pattern and when is it used with service-based architecture?
?
Backend for Frontend (BFF) is a variant of the API gateway pattern where a dedicated gateway (or lightweight service) exists per UI surface — one BFF for the web app, one for mobile app, one for third-party API consumers. Each BFF is optimized for its client’s specific data needs (different response shapes, different aggregations). Used when: (1) web and mobile have significantly different data requirements; (2) the monolithic API gateway becomes a bottleneck; (3) separate teams own different client surfaces.
What governance mechanisms enforce service independence in service-based architecture?
?
Four key mechanisms: (1) API contract versioning — OpenAPI specs, Protobuf schemas, versioned endpoints (/v1/, /v2/); (2) Consumer-driven contract tests — Pact tests run in CI verify provider changes don’t break consumers; (3) Schema ownership policy — each DB table has one owning service; enforced via separate DB users per schema; (4) Service count policy — target service count defined as an architectural decision; new services require an ADR justifying the split.
Why does service-based architecture have ★★★★☆ simplicity compared to microservices ★★☆☆☆?
?
Service-based architecture’s coarse granularity is the source of its simplicity advantage. With 4–12 services: fewer deployment units to manage; fewer inter-service communication paths; simpler service discovery; often a shared database (no distributed transactions); no need for a full service mesh; simpler distributed tracing. Microservices with 50+ services requires sophisticated infrastructure to manage. Service-based gets most of the agility benefit with a fraction of the operational burden.
What is the team topology recommendation for service-based architecture?
?
Ideal: one team per service (for larger organizations) — the team owns the service end-to-end: design, development, database schema, CI/CD pipeline, and production operations. For mid-size organizations: 2–3 services per team. A platform team owns the API gateway, shared libraries, CI/CD infrastructure, and observability platform. If the UI is monolithic, a UI team manages the frontend (risk: UI team becomes a bottleneck). Teams align with DDD bounded contexts — each service corresponds to one bounded context.
What is a shared library risk specific to service-based architecture with a shared database?
?
When services share a database AND use a shared library that encapsulates database entities (ORM models), a schema change requires: updating the library, versioning it, and coordinating deployment across all services that import it. If services cannot be deployed independently due to this coordination requirement, the system has become a distributed monolith — services that look separate but must release together. This is one of the most common service-based architecture failure modes.
Priority: HIGH — Service-based architecture is the most commonly implemented distributed style in enterprise environments and the most likely architecture style question in system design interviews. Master the data topology options and the comparison with microservices and monolith.