System-Design on Roman Empire

CAP

contact@romanempire.dev (Roman) — Fri, 15 May 2026 00:00:00 +0000

CAP Theorem A.K.A Brewer’s Theorem is a principle in distributed systems that states that it is impossible for a distributed system to simultaneously provide all 3 guarantees

Consistency
#

Ensures all nodes in the distributed system have the same data at the same time. Change in one node should also be reflected in all nodes.

ACID

contact@romanempire.dev (Roman) — Thu, 14 May 2026 00:00:00 +0000

ACID properties are the guarantees a database must provide for transactions to be reliable.

Atomicity
#

All or nothing; if any step fails, the whole transaction rolls back.

Example

Transferring £100 from A to B requires two steps: debit A, credit B. If the credit fails, the debit is rolled back. Money never vanishes in transit.

CQRS and Event Sourcing

contact@romanempire.dev (Roman) — Mon, 11 May 2026 00:00:00 +0000

In most systems, reads and writes don’t scale the same way, and they rarely need the same data shape. As domains grow more complex, forcing a single model to handle both creates bloated entities and scaling bottlenecks. This article covers two patterns that address this directly: CQRS, which separates the write and read paths, and Event Sourcing, which replaces mutable state with an append-only log of what happened.

CQRS
#

Command Query Responsibility Segregation

API

contact@romanempire.dev (Roman) — Wed, 15 Apr 2026 00:00:00 +0000

API Paradigms
#

REST (Representational State Transfer)

Characteristics:
- Stateless architecture
- Uses standard HTTP methods (GET, POST, PUT, DELETE)
- Typically uses JSON for data exchange
- Resource-oriented design
Pros:
- Simple and widely adopted
- Scalable and cacheable
- Separation of client and server
Cons:
- Potential for over-fetching or under-fetching data
- Multiple round trips for complex data requirements

GraphQL

Characteristics:
- Single endpoint for all operations
- Strongly typed schema-based queries
- Allows clients to request specific data
Pros:
- Avoids over-fetching and under-fetching
- Flexible data retrieval
- Strong typing and introspection
Cons:
- Complex queries can impact server performance
- Always responds with HTTP 200 (error handling complexity)
- Steeper learning curve

gRPC (Google Remote Procedure Call)

Characteristics:
- Built on HTTP/2 protocol
- Uses Protocol Buffers for serialization
- Supports streaming (unary, server, client, bidirectional)
Pros:
- High performance and low latency
- Efficient binary serialization
- Strong typing with protocol buffers
- Supports multiplexing and server push
Cons:
- Less human-readable (binary format)
- Requires HTTP/2 support
- Limited browser support
- Steeper learning curve compared to REST

Use Cases

S.O.L.I.D. Principles

contact@romanempire.dev (Roman) — Tue, 14 Apr 2026 00:00:00 +0000

SOLID is a set of five object-oriented design principles, that guide writing maintainable, scalable, and testable code. Each letter stands for a principle that, when followed together, reduces tight coupling and makes systems easier to extend without breaking existing behavior.

Core Principles

S - Single-responsibility Principle

O - Open-closed Principle

L - Liskov Substitution Principle

I - Interface Segregation Principle

D - Dependency Inversion Principle

Single-Responsibility Principle
#

A class should have one and only one reason to change, meaning that a class should have only one job.

System-Design on Roman Empire

CAP

Consistency #

ACID

Atomicity #