Understand the business
Map borrowers, lenders, products, applications, decisions, finance, servicing and operations before deciding on services.
← Original ClearLend showcase
Mentoring series · Microservices master class
Learn to design ClearLend as microservices.
Follow fictional people as they use ClearLend. Each chapter explains their goal, a possible design choice, its cost and the result a person should see. We teach with words and diagrams.
Stage 1 available · Stages 2–12 coming soon · Design lessons only
01 / The reason
Microservices must solve an ownership problem, not decorate a CV.
The original ClearLend series chose a layered modular monolith. That was a sensible design: one deployable application is easier to understand, transact, debug and operate while a product is still being discovered.
This new master class explores the point at which meaningful independence could justify a distributed system. Applications and lender products may change at different speeds. Finance needs stricter controls than product browsing. Notifications and reporting should fail without stopping a borrower from saving a draft. Different teams may need to release and scale their capabilities independently.
Microservices are not small APIs. They are independently manageable business capabilities with owned data, explicit contracts and operational responsibility.
We will also show the cost: network failures, eventual consistency, duplicate messages, contract evolution, cross-service security, more deployment paths and harder debugging. If two services become permanently chatty or cannot change independently, we will consider merging them.
02 / A fresh design
We carry forward the business story.
The earlier project supplies the fictional business setting. This course shows how a team could design microservices from the beginning. It is a website book, not a ClearLend application.
Design one complete journey
Draw what a borrower would see and how proposed parts would respond.
Explain each technology
Show when a database, message broker, cache or cluster would help and what it would cost.
Before Stage 1 / The dependency order
Start with a person, then choose the tools.
A dependency is something we need before we can make the next decision. We cannot choose a database for a product before we know who owns the published terms and what Amina needs to see.
- 1Person and goal. Amina wants to read a product Daniel has published. Write down who needs help before drawing services.
- 2Permission and visible result. Amina may read published terms. Daniel may prepare them. Agree what each person may see or change.
- 3Fact and owner. Decide who should give the official answer about published terms and their version. Stage 1 proposes Product Catalog as the owner.
- 4Success and failure. Describe what Amina sees when the product is published, missing or still a draft. Draft terms must stay private.
- 5Smallest useful boundary. Ask whether Catalog needs its own service or can begin as a responsibility in one organised application.
- 6Diagram and tradeoff. Draw the proposed journey. Explain another reasonable choice and what each choice would cost.
- 7Later infrastructure. Discuss a database, gateway, broker, cache, container or cloud service when a later lesson shows the problem it could solve.
Then explain possible dependencies
After the journey is clear, discuss what tools a real team might need and what each would add. The course does not install or run those tools.
03 / Possible architecture
One borrower journey, several possible owners.
This diagram is a proposal to test against later journeys. It does not show a system we have built or deployed. We may use fewer services.
One owner for each fact
A proposed service should have a clear answer to what it owns.
Explain a transaction
Show which changes would succeed together and which could finish later.
Draw failure paths
Show what a person would see if another part were unavailable.
Plan how to investigate
Explain what evidence a support person would need without exposing private data.
04 / Possible service ownership
Services follow business jobs, not database tables.
These are proposed boundaries. The tools and data stores shown below are questions for later stages, not decisions already implemented.
Data choice later
Party & Onboarding
Owns: Borrower and lender profiles, vetting state and eligibility snapshots.
Why: Keeps one official answer about a person and their checks.
Data choice later
Product Catalog
Owns: Versioned lender products, publication state and eligibility descriptions.
Why: Keeps the official published terms separate from a lender’s draft.
Data choice later
Applications
Owns: Drafts, submissions, requested amounts, ownership and concurrency.
Why: Keeps the borrower’s request and its changes in one place.
Data choice later
Decisions & Offers
Owns: Review cases, reasons, exact offer terms, expiry and acceptance.
Why: Records why a decision was made and which offer was accepted.
Data choice later
Finance & Settlement
Owns: Commitments, payment attempts, reconciliation and financial entries.
Why: Tracks money movement and explains corrections.
Data choice later
Servicing
Owns: Active loans, schedules, balances, arrangements and closure.
Why: Tracks what happens after a loan becomes active.
Data choice later
Notifications
Owns: Delivery requests, templates, preferences, attempts and outcomes.
Why: Delivery failures must remain independent from lending decisions.
Data choice later
Operations read models
Owns: Purpose-built support, compliance and owner dashboards.
Why: Gives support staff useful views without changing the official records.
05 / Possible technology
Every component must have a reason.
These are topics we may explain in later chapters. A named person's problem should give each tool a reason. None has been added to a ClearLend application.
ASP.NET Core
Discuss where business APIs and background work might belong.
Angular + BFF
Discuss how a browser journey could avoid depending on internal service details.
SQL Server
Discuss when transactional data might need a relational store.
PostgreSQL
Compare another relational option and explain why a team might choose it.
MongoDB
Discuss whether changing product structures justify a document store.
Redis
Discuss faster reads alongside the risk of showing old information.
Azure Service Bus
Explain delayed work, messages and duplicate delivery through a person’s journey.
Docker + Aspire
Explain how a team could plan a repeatable local setup.
OpenTelemetry
Explain what evidence could trace a delayed borrower journey.
Kubernetes + AKS
Explain how a team might run and recover containers on Azure.
Bicep + Key Vault
Explain how a team might plan resources and protect secrets.
CI/CD
Explain how a team could check and release changes safely.
Example question for later
If product browsing became slow, could a cache help Amina? We would first ask why it is slow and explain how old product information could affect her. Redis is a teaching topic here.
06 / The first journey
A small example helps us check the design.
This is a fictional story used to explain design choices. Stage 1 teaches Amina's product-reading question. Later chapters will discuss the other steps. None is a working feature.
- 1Daniel prepares proposed product terms.
- 2Amina wants to read the public version.
- 3Amina may later save and submit an application draft.
- 4Priya may review a submitted application.
- 5Sam may investigate a delayed outcome.
07 / Twelve teaching stages
From service boundaries to Azure operations.
We write and review one chapter at a time. Stage 1 is ready to read.
Chapter availability: Stage 1 is available. Stages 2–12 are Coming soon and do not open pages.
01Stage published
Find the service boundaries
Follow Amina’s product-reading story and decide who should own the published terms.
- Borrower journey
- Product ownership
- Design tradeoff
02Coming soon
Plan the engineering foundation
Follow a borrower who wants to save a draft and decide where each rule belongs.
- Draft journey
- Work areas
- Dependency direction
- Design checks
03Coming soon
Design a walking skeleton
Draw a proposed request path through an entry point, Catalog and Applications.
- Entry point
- Example contracts
- Failure
- Correlation
04Coming soon
Understand containers
Learn what an image is and how a team could plan a local container setup.
- Dockerfiles
- Docker Compose
- .NET Aspire
- Health and shutdown
05Coming soon
Give services private data
Compare SQL Server, PostgreSQL and MongoDB for different service needs.
- Database per service
- Migrations
- Provider tests
- Backups
06Coming soon
Connect services safely
Design synchronous APIs, asynchronous events and gateway policy.
- REST contracts
- API gateway
- Service Bus
- Versioning
07Coming soon
Control distributed consistency
Explain how a team could recover delayed, duplicated and partly completed work.
- Outbox and inbox
- Idempotency
- Saga workflow
- Dead letters
08Coming soon
Add cache, security and resilience
Improve speed and safety while keeping failure bounded and visible.
- Redis
- OAuth/OIDC
- Timeouts
- Load shedding
09Coming soon
Plan observation and tests
Learn how a real team could check contracts, workflows and user journeys.
- OpenTelemetry
- Component tests
- Contract tests
- Failure exercises
10Coming soon
Learn Kubernetes clearly
Understand raw workload resources before introducing packaging abstractions.
- YAML
- Deployments
- Probes and scaling
- Network policy
11Coming soon
Plan the Azure platform
Learn what AKS, identity, networking, secrets and managed services would need.
- Bicep
- AKS
- Workload Identity
- API Management
12Coming soon
Plan operations and improvement
Explore releases, recovery, service goals, performance and cost.
- CI/CD
- SLOs and runbooks
- Performance
- Capstone review
08 / Where we are
Start with the Stage 1 lesson.
Stage 1 explains Amina's product journey and a proposed ownership boundary with words and diagrams. Stages 2–12 are still being prepared. Each later chapter will begin with a teaching plan for review.
No ClearLend microservices application, API, database, container or Azure platform exists. The diagrams show proposals.
Follow the lessons
Learn the reasons behind each design choice.
The original ClearLend series explains the product and layered architecture. This new master class follows the same fictional marketplace into service ownership, messaging, containers, Kubernetes and Azure operations.