Skip to content

a distributed enterprise system · 2022 · university project

Distributed Enterprise System

A university project where I built a system the enterprise way: several services, each owning its own data, talking over REST. Most of what I know about the boundaries between services I learned by getting them wrong here first.

Layers
application, services, data
Built with
SOA · Microservices · Service Architecture · Enterprise Patterns
Elsewhere
source on GitHub
SERVICE ZONE · PRIVATE NETWORK PUBLIC EDGE client browser · JSON gateway auth · JWT rate limit route · retry REST · HTTP/1.1 account :8081 ctrl svc repo accounts person :8082 ctrl svc repo persons bank :8083 ctrl svc repo banks ONE STORE PER SERVICE GET /persons/{id} ONE REQUEST, TIMELINE · req 7f3a client gateway account person t=0 · POST /transfer +4 ms · auth ok +11 ms · owner? +23 ms · 200 +31 ms · 201 created +33 ms timeout 800 ms · 2 retries 1 2 3 4 5 6
Fig. 01 — Services behind a gateway, each with its own store, talking over REST. Below, one request crossing them.
  1. 1API gateway · auth, rate limit, routing with retry
  2. 2Service · controller, service and repository layers
  3. 3Store · one database per service, nothing shared
  4. 4REST · JSON over HTTP, versioned paths
  5. 5Service-to-service call · account asks person who owns what
  6. 6Timeout and retries · fail fast, log with the request id

The problem

A university course on enterprise systems, with a deliberately uncomfortable brief: build a system the way large organisations do, as several independent services that have to cooperate without sharing a database.

What I built

A set of microservices2, each owning one business domain and its own data store3, talking to each other over RESTful APIs4 behind a gateway1. I applied the patterns the course was about, Repository, Service Layer and DTOs, and spent most of the effort on the boundaries: how a service asks another for something it does not own5, what happens when that call fails6, and how to log across services so that a problem can be traced from end to end.

What I learned

Most of what I know about the boundaries between services I learned by getting them wrong here first. Splitting a system is easy; deciding what each piece owns is the real design work. Those lessons carried straight over to the cloud side of the IoT work later, where machines and services talk over unreliable networks.