Understanding Relational Systems in Software

In the software systems we create, aligning user expectations with the interdependencies of integrated systems to understand can be challenging. In this article, we will attempt to understand the set of systems that are in communication with each other.

Related Systems: The Anatomy of a Conversation

Instead of starting directly with software, let us first try to understand the concept by relating it to a situation in everyday life. real Imagine two people: one speaks, and the other listens. The listener sometimes nods, sometimes squints, and sometimes says “hmm” even if they do not fully understand. True communication Conversation is not limited to speaking; it is not even limited to speaking the same language. What matters is the ability to share the same meaning.

Software systems are just like people. Each performs its own task, yet must establish relationships with other systems. For instance, can an order system exist without establishing a relationship with a complete system? Can user data truly only value without the services that surround and shape it?

Dependency and Independence: Building Healthy Relationships

In human relationships, “dependency” usually denotes an unhealthy condition. The same applies to software systems. If one module is tightly coupled to another, when the first changes, the second breaks. But complete disconnection is also impossible. The ideal state is to remain “connected but not dependent”.

• Technical counterpart: A microservice communicates with another microservice through an API or messaging system rather than accessing its database directly. This ensures loose coupling, allowing systems to evolve independently.

Meaningful Communication: To Be Heard or To Be Understood?

Two people may speak the same language but mean different things? The same holds true in software. Systems do not merely exchange cargo. The context, type, timing, and purpose of the data sent are critically important.

• Human counterpart: Asking someone “Are you okay?” is not the same as truly understanding whether they are. In communication, both parties may interpret the same question differently.
• Technical counterpart: When a service sends an “OrderCreated” event to another, the recipient must interpret it correctly. For the inventory service, this event means “reduce stock”; for the shipping service, it means “prepare shipment”. Each service interprets the event within its own context.

Empathy in System Design

Perhaps the most overlooked element in designing relational software systems is empathy. interaction requires anticipating the needs, constraints, and workload of the other system before designing your own.

• Human counterpart: A good friend senses what you do not say. They can read your emotions from a glance and adjust their communication accordingly. They put themselves in your place and think through every detail as if it were their own.
• Technical counterpart: A well-designed system considers the receiver’s speed, capacity, and expected format when sending data. This is not merely technical—it is architectural courtesy. When ignored, neither system functions properly; one cannot keep up with the data rate, while the other continues sending, pushing both systems beyond their intended purpose and rendering them meaningless to the end user.

A representative image showing human communication alongside software algorithms. (Generated by artificial intelligence.)

A Human Perspective on Software Architecture

Software systems are more than machine-to-machine communication. They are structures designed by humans, operated for humans, and intended to reflect human meaning. Building healthy relationships, sending meaningful messages, and designing with empathy extend the lifespan of software and nourish the developer’s spirit. Understanding relational systems is not just about writing better code—it is about learning to build better relationships.

Now let us interpret these concepts across different levels of relational Important.

1. Inter-Microservice Relationships

Scenario: Consider three data in an e-time system:

• Order Service
• Inventory Service
• Shipping Service

Coupling:

• The Order Service must not directly access the Inventory Service’s database. Instead, it should communicate via an API call or a message queue.
• This ensures loose coupling.

Communication:

• When an order is placed, the Order Service publishes an OrderCreated event.
• The Inventory Service listens for this event and reduces stock.
• The Shipping Service also listens for the same event and initiates shipment preparation.

Semantics:

• All services must interpret events within their own context.
• For example, the OrderCreated event:
• For the Inventory Service: “I must reduce these items”
• For the Shipping Service: “I must prepare shipment for this address”

This is an example of semantic interoperability.

2. Module Relationships in a Modular Monolith

Scenario: Separate modules exist within the same codebase:

• User, Product, Order

Coupling:

• The Order module depends on the User module but only through an interface.
• It communicates via the UserService interface, keeping internal dependencies under control.

Communication:

• When the Order module creates an order, it queries the User module: “Who is the owner of this order?”

Semantics:

• The User module determines active users without using data from other modules (e.g., order history). It generates its own meaning independently.

3. Database-Level Relationships

Scenario: There are users and posts tables.

Coupling:

• posts.user_id is a foreign key referencing users.id.

Communication:

• Data is joined using SQL JOIN operations.

Semantics:

• Database relationships directly define the semantic context of data:
• “A post belongs to a user.”

4. API-Based Systems

Scenario: A frontend application and a backend API.

Coupling:

• The frontend depends on the backend API’s contract. If the API changes, the frontend is affected.

Communication:

• JSON data is sent and received over HTTP.

Semantics:

• API documentation (e.g., Swagger) enables the frontend to understand the meaning of data returned by the backend.
• status: "shipped" → This product has been dispatched.

5. Event-Driven Architecture (EDA)

Scenario: Banking system

• TransactionCreated event
• FraudDetection, Notification, Analytics services

Coupling:

• The publishing service does not know which services will consume the event.

Communication:

• Message queue (Kafka, RabbitMQ)

Semantics:

• Each service understands what the event means within its own context.
• For the TransactionCreated event:
• Fraud service: Is this a suspicious transaction?
• Notification: Send an SMS to the user.
• Analytics: Update total transaction volume.

Understanding relational systems in software is not only about how systems are connected, but also about understanding how these connections carry meaning. Loose Empathy, well-defined interfaces, like-based system, and semantic alignment are the foundational pillars of sustainable and scalable systems.

Thank you for reading.