Chapter 7 Flashcards — Service Granularity
flashcards saht service-granularity distributed-architecture
What are granularity disintegrators?
?
Architectural forces that push toward splitting a service into smaller, more focused pieces. The six disintegrators are: (1) service scope/function, (2) code volatility, (3) scalability/throughput, (4) fault tolerance, (5) security, (6) extensibility.
What are granularity integrators?
?
Architectural forces that push toward merging or keeping services together. The four integrators are: (1) database transactions, (2) workflow/choreography chattiness, (3) shared business code, (4) tight data relationships.
What is the “single-purpose principle” for services?
?
A service should have one well-defined responsibility — it should do one thing well. If you cannot describe the service’s purpose without the word “and,” it is likely violating this principle and is a candidate for splitting (scope/function disintegrator).
What does code volatility signal for service granularity?
?
When different parts of a service change at very different rates, they should be separated into distinct services. High-volatility code should not force redeployment of stable, low-volatility code. Mixing them increases deployment risk and frequency for the stable parts unnecessarily.
Why is scalability a granularity disintegrator?
?
If one function within a service receives dramatically more traffic than others, running them together forces you to scale the entire service to handle the hot function — wasting resources on parts that don’t need it. Splitting enables independent scaling of the high-throughput component only.
What is fault tolerance as a granularity disintegrator?
?
Functions with different failure risk profiles should be separated. If one function calls an unreliable external system, it should be isolated so its failures don’t bring down unrelated, stable functionality. Splitting limits the blast radius of failures.
Why is security a reason to split a service?
?
Functions handling sensitive data (PII, PCI, PHI) should be isolated in their own service to: (1) minimize the attack surface, (2) apply stricter network and access controls, (3) simplify compliance scope, and (4) allow independent security auditing. Other services should not share process space with sensitive data handlers.
What does extensibility as a disintegrator mean in practice?
?
If a function is likely to have its implementation replaced or will grow significantly in scope (e.g., a single-carrier shipping integration that will expand to multi-carrier), separating it now allows the extensible part to evolve without impacting stable, adjacent functionality.
Why are database transactions the strongest granularity integrator?
?
ACID transactions cannot span service boundaries without significant complexity (two-phase commit or saga patterns). If two operations must be atomic and you cannot tolerate eventual consistency between them, keeping them in one service is almost always the right choice. Distributed transactions are a last resort.
What is the “chatty services” problem?
?
When services are so fine-grained that a single business operation requires many sequential inter-service calls (e.g., 8+ hops), the result is: high latency (each hop adds 10-100ms), increased failure probability, and complex error handling. This is a sign of over-decomposition — the workflow integrator suggests merging some services.
What distinguishes shared infrastructure code from shared business code for granularity decisions?
?
Shared infrastructure code (logging, retry logic, circuit breakers, tracing) is fine to share via a library — it is not a merging signal. Shared business logic (domain rules, eligibility calculations, pricing logic) that changes in sync across services indicates those services may belong in the same bounded context and is a merging signal.
What does the data relationships integrator say?
?
If data in two services is always accessed together, has tight referential relationships (foreign keys), and is frequently joined in queries, keeping the data (and therefore the services) together avoids complex API composition, in-memory joins, and consistency issues across service boundaries.
What is the practical “naming test” for service granularity?
?
If you cannot describe the service’s purpose in one sentence without the word “and”, the service is likely doing too many things and is a candidate for splitting. E.g., “The CustomerService manages customer profiles AND notification settings AND address book AND payment methods” — this is too broad.
What is the “deployment cadence” rule for granularity?
?
Services that always deploy together — meaning a change to one always requires deploying the other — probably belong in the same service. If independent deployability is supposed to be a benefit of decomposition but you are deploying two services in lockstep, you are paying the cost of decomposition without gaining the benefit.
When does the scalability disintegrator outweigh the transaction integrator?
?
When the scalability difference is extreme (e.g., 100:1 traffic ratio) and you can tolerate eventual consistency between the operations, split the service and use asynchronous messaging or an outbox pattern to maintain eventual consistency — avoiding the distributed transaction while still enabling independent scaling.
What is the “start coarser” heuristic for granularity?
?
When the right granularity is unclear, err on the side of a larger, coarser service and split later when a disintegrating force becomes clearly dominant. It is operationally easier to split a service (extract code, migrate data) than to merge two already-separated services (different teams, databases, deployment pipelines, clients).
In the Sysops Squad ticket assignment example, which forces drove the split decision?
?
Disintegrators that won: code volatility (assignment logic changes frequently; creation logic is stable), scalability (assignment is compute-intensive; creation is lightweight), and extensibility (ML-based routing planned for assignment only). The transaction integrator was addressed by accepting eventual consistency — a ticket can briefly exist unassigned.
In the Sysops Squad customer registration example, why were the services kept together?
?
The transaction integrator dominated: a customer must have notification preferences as part of a valid registration — creating the customer without preferences is an inconsistent state. The data relationship integrator reinforced this: profile and notification data are always accessed together. The scope/function disintegrator (they are different capabilities) was insufficient to overcome these.
What is the granularity tension when security isolation is needed but data is tightly related?
?
Security isolation (disintegrator) generally wins when compliance requirements mandate it (PCI-DSS, HIPAA). The solution is to split the services, use strict API access controls, encrypt data in transit and at rest, and accept the overhead of cross-service calls — rather than co-locating sensitive and non-sensitive data handling.
What does it mean for granularity that services should pass the “two-pizza team test”?
?
A service’s scope and complexity should be ownable by a small, autonomous team (roughly 2-8 people). If a single service requires multiple teams to maintain it (because different teams own different parts of it), its scope is too broad and it should be split — likely along team ownership boundaries.
How does code volatility differ from extensibility as a disintegrator?
?
Code volatility is about the current rate of change — parts that change frequently now should be separated from stable parts to reduce deployment risk. Extensibility is about anticipated future change — parts likely to have their implementation replaced or significantly grown should be separated now to enable future evolution without impacting stable parts.
What is the relationship between granularity and bounded contexts?
?
Service boundaries should generally align with bounded context boundaries from Domain-Driven Design. If two services share domain concepts, business rules, or ubiquitous language that are tightly intertwined, they likely belong to the same bounded context — which is a merging signal. Services that span bounded contexts violate context integrity.
Why can “shared code” across services become a granularity problem even with a shared library?
?
If business logic is extracted into a shared library and many services depend on it, a change to the shared logic requires: (1) updating the library, (2) releasing a new version, (3) updating each dependent service to use the new version, and (4) deploying all updated services. This creates coordinated deployment coupling — undermining the independence benefit of microservices. It suggests the logic’s ownership needs to be reconsidered.
What are the four granularity integrators in order of typical influence?
?
- Database transactions — strongest; ACID requirements almost always win
- Workflow/choreography — very strong; severe chattiness indicates over-decomposition
- Data relationships — strong; tightly coupled data suggests co-location
- Shared business code — moderate; depends on how much code is shared and how often it changes
Complete this decision rule: “If two operations must be atomic and you cannot tolerate eventual consistency between them, then ___.”
?
“…keep them in the same service.” Distributed transactions (2PC or sagas) are complex, slow, and error-prone. The transactional integrator is the most compelling reason to maintain or increase service granularity. Only pursue distributed transactions when splitting is unavoidable due to dominant disintegrating forces.
What is the core message of Chapter 7 about “best practices” for service size?
?
There is no universal right service size. The correct granularity is determined by context: the specific mix of disintegrating forces (volatility, scalability, security, etc.) and integrating forces (transactions, workflow, shared code, data) present in each service. Architects must evaluate both sets of forces explicitly and make a conscious trade-off decision — not follow a rule of thumb like “one service per entity” or “microservices should be small.”
Total Cards: 25
Priority: HIGH
Last Updated: 2026-05-30