Understanding Microservices Fundamentals

1. Understanding Microservices Architecture

Aspect	Description	Implication
Definition	Architectural style where applications are composed of small, autonomous services	Each service owns a single business capability
Service Size	Small enough to be owned by one team (2-pizza rule)	Typically 100-10K LOC per service
Communication	Network-based via APIs (REST, gRPC, messaging)	Higher latency than in-process calls
Data Storage	Each service owns its database (Database per Service)	No shared schemas between services
Deployment	Independently deployable artifacts (containers, serverless)	Enables continuous delivery per service
Technology Stack	Polyglot — each service can use optimal tech	Java, Go, Node.js, Python coexist

High-Level Architecture

   [Client] → [API Gateway] → ┬── [Order Service] ── [Order DB]
                              ├── [Payment Service] ── [Payment DB]
                              ├── [Inventory Service] ── [Inventory DB]
                              └── [Notification Svc] ── [Notification DB]
                                         ↕
                              [Message Broker (Kafka)]

2. Understanding Microservices Characteristics

Characteristic	Meaning	Benefit
Autonomy	Independently developed, deployed, scaled	Team velocity, fault isolation
Decentralized Governance	No central architecture committee dictates tech	Tech diversity, faster innovation
Decentralized Data	Each service owns its persistence	Schema evolution without coordination
Smart Endpoints, Dumb Pipes	Logic in services; messaging is plain transport	Avoids ESB-style complexity
Design for Failure	Network/services WILL fail; build resilience in	Higher availability
Evolutionary Design	Services replaced/refactored independently	Lower change cost
Infrastructure Automation	CI/CD, IaC, container orchestration	Manageable at scale

3. Understanding Service Boundaries

Heuristic	Rule	Anti-Pattern
Business Capability	One service per stable business function	Splitting by technical layer (UI/DB)
Data Cohesion	Data that changes together lives together	Joining across service DBs
Change Frequency	Group code that changes together	Co-deploying unrelated services
Team Topology	One team per service (Conway's Law)	Multiple teams editing same service
Transactional Boundary	One ACID transaction = one service	Distributed transactions across services

Example: E-commerce Service Boundaries

Catalog Service        → Products, categories, search
Order Service          → Cart, checkout, order lifecycle
Payment Service        → Payment processing, refunds
Inventory Service      → Stock levels, reservations
Shipping Service       → Carriers, tracking, delivery
Customer Service       → Profiles, addresses, preferences
Notification Service   → Email, SMS, push notifications

4. Understanding Service Independence

Dimension	Independent	Coupled (Bad)
Build	Separate repo/pipeline per service	Monorepo with single build
Deploy	Deploy v2 of A without redeploying B	Lockstep releases
Scale	Scale A to 100 replicas, B stays at 2	Scale entire app together
Database	Each service owns DB schema	Shared tables across services
Runtime	Failure of A degrades but doesn't crash B	Cascading failures

Warning: If you cannot deploy a service independently, it's not a microservice — it's a distributed monolith.

5. Understanding Single Responsibility Principle

Question	Answer Indicates
"Why would this service change?"	If multiple unrelated reasons → split it
"Who owns the requirements?"	Multiple stakeholders → split by stakeholder
"What is its single business capability?"	If you can't state it in one sentence, refactor
"Does it have one source of truth?"	Yes → good cohesion; No → too broad

6. Understanding Microservices vs Monolith

Dimension	Monolith	Microservices
Deployment	Single artifact, all-or-nothing	Independent per service
Scaling	Scale entire app	Scale per service
Tech Stack	Single stack	Polyglot
Data	Single shared DB	Database per service
Team Coordination	High (shared code)	Low (autonomous teams)
Operational Complexity	Low	High (network, observability)
Initial Velocity	Fast	Slow (infrastructure setup)
Long-term Velocity	Slows with size	Sustains with size
Best For	Small teams, early product	Large orgs, mature product

Note: Start with a well-structured modular monolith. Extract microservices when team size, change frequency, or scaling needs justify the complexity.

7. Understanding Distributed Systems Challenges

Fallacy	Reality	Mitigation
Network is reliable	Packets drop, partitions occur	Retries, circuit breakers
Latency is zero	RTT can spike to seconds	Timeouts, async, batching
Bandwidth is infinite	Throttling, congestion happen	Compression, pagination
Network is secure	Threats inside and out	mTLS, zero-trust, encryption
Topology never changes	Instances scale, IPs change	Service discovery
One administrator	Many teams, many clouds	Federated governance
Transport cost is zero	Serialization, marshalling cost CPU	Efficient formats (Protobuf)
Network is homogeneous	Mix of clouds, regions, protocols	Adapters, gateways

8. Understanding Service Granularity

Granularity	Indicators	Risk
Too Coarse (Mega Service)	>3 teams, multiple capabilities, slow deploy	Becomes mini-monolith
Right-Sized	One team, one capability, focused API	—
Too Fine (Nanoservice)	Trivial logic, high inter-service chatter	Network overhead, ops burden

Note: Optimize for cognitive load and deploy independence, not for "smallest possible" services.

9. Understanding Service Ownership

Aspect	Owning Team Responsibility
Code	Repo, PRs, code reviews, tech choices
Build & Deploy	CI/CD pipelines, release cadence
Runtime	SLOs, on-call, incident response
Data	Schema, migrations, retention
API Contract	Versioning, deprecation, docs
Cost	Cloud spend, optimization

"You Build It, You Run It"

Devs own production operation, not a separate ops team
Reduces feedback loop between defects and fixes
Drives quality through accountability

10. Understanding Conway's Law

Concept	Description
Conway's Law	"Organizations design systems that mirror their communication structure"
Inverse Conway Maneuver	Restructure teams to drive desired architecture
Team Topologies	Stream-aligned, Platform, Enabling, Complicated-subsystem teams
Cognitive Load	Each team owns services within its mental capacity (~5-9 services)
Communication Cost	Cross-team dependencies → API contracts; intra-team → code