Chapter 21 — Web3, blockchain and cryptoasset security: service integration
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Integrating services"]
N2["21.2 Handling failures between services"]
N3["21.3 Protecting credentials"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 Integrating services"]
N2["21.2 Handling failures between services"]
N3["21.3 Protecting credentials"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 Integrating services]
|
v
[21.2 Handling failures between services]
|
v
[21.3 Protecting credentials]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) integrate the ledger with business services; (2) handle failures between services; (3) protect service credentials.
21.1 Integrating services
The booking application, the issuing service, an email notification service and the makerspace's accounting software all interact with the ledger. Lucas documents each integration: what it reads or writes, which node it uses, which credentials it holds and what happens if it fails. He finds that the accounting export reads balances directly from the ledger each night, while the booking system uses its own cached copy. If they disagree, staff may be confused. He proposes a single nightly snapshot used by both, which simplifies reconciliation and reduces the number of reads against nodes.
21.2 Handling failures between services
Services fail independently. If a node is unavailable, the booking application should switch to another; if the issuing service fails mid-batch, it must not grant credits twice when restarted; if the email service is down, bookings should still proceed and notices queue. Lucas reviews each service's behaviour on failure using the test ledger and finds that the issuing service lacks a record of completed batches. The developer adds one, so a restart resumes safely. Designing for failure between services prevents small outages from causing incorrect credits or lost bookings.
21.3 Protecting credentials
Each integration uses credentials: database passwords, node access tokens and email service keys. Lucas moves them from configuration files into the server's protected secret store, gives each service its own credential, and sets rotation dates. No service shares credentials with another, so a leak affects only one. He also confirms that the issuing service cannot sign grants itself; it only prepares batches for human signers. Separating preparation from signing keeps the most powerful action, creating credits, under human control even if a service is compromised.
Worked example
Lucas proposes a shared nightly snapshot, gets a completed-batch record added to the issuing service and moves credentials into a protected store, one per service.
Synthetic case. The integrations and credentials are synthetic.
Errors and limits
Sharing one credential across services lets a single leak affect all of them.
Exercises
- EX061 — Snapshot proposal. What does Lucas propose for balances? Rubric: 3 = a single nightly snapshot used by booking and accounting;; 2 = shared snapshot;; 1 = more reads;; 0 = none.
- EX062 — Restart safety. What did the issuing service lack? Rubric: 3 = a record of completed batches;; 2 = batch record;; 1 = a logo;; 0 = none.
- EX063 — Signing separation. Can the issuing service sign grants? Rubric: 3 = no, it only prepares batches for human signers;; 2 = no;; 1 = yes;; 0 = none.
Synthesis
Documented integrations, failure-aware design and separate credentials make services safe together.
Continue studying — chapter 21 of 30
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →