Unary RPC

What Unary RPC Means in Practice

Unary RPC is the most straightforward remote procedure call pattern: one request in, one response out. That simplicity makes it a natural fit for discrete operations, especially when the client needs a single result or confirmation rather than a stream of updates.

Because the interaction is bounded, unary RPC is often easier to design, test, and observe than long-lived or bidirectional patterns. The trade-off is that every operation has to fit within one round trip, so it is less suitable for continuous feeds, interactive sessions, or event-rich workflows.

Where Unary RPC Fits in API and Service Design

Unary RPC maps cleanly to common business actions such as creating a resource, retrieving a record, or submitting a change. It is usually the right choice when the client can express the full intent up front and the server can complete the work without further back-and-forth.

That makes it attractive for service interfaces that need predictable semantics and a clear success-or-failure outcome. In distributed systems, this predictability helps teams reason about latency, retries, idempotency, and error handling more easily than with stateful or streaming interactions.

Operational Characteristics and Failure Modes

Unary RPC tends to be operationally simple, but it still depends on network reliability, timeouts, and careful request design. If the request is too large, the operation is too slow, or retries are not managed well, the apparent simplicity can hide duplicate processing or inconsistent outcomes.

Its one-request, one-reply shape also means the caller must wait for completion before continuing. That is efficient for small, discrete tasks, but it can become a bottleneck when the underlying action is slow, highly variable, or likely to benefit from asynchronous handling.

Unary RPC Compared with Other Interaction Patterns

Unary RPC is best understood as one point on a spectrum of remote communication styles. Compared with server streaming or bidirectional streaming, it is less expressive but easier to instrument and govern; compared with ad hoc HTTP usage, it is often more strongly typed and more explicit about the contract between client and server.

That contract clarity is one reason unary RPC is widely used in internal service-to-service APIs. It supports a clean separation between the caller’s intent and the server’s implementation, which is useful when the service is acting as a narrow command or query endpoint.

Risk and Threat Considerations

Unary RPC itself is not inherently risky, but it becomes security-sensitive when it carries privileged actions, sensitive data, or attacker-controlled input. A weak implementation can expose the same classes of failure seen in other APIs, especially authentication gaps, broken authorization, replayable requests, and uncontrolled resource use.

Failure mechanism: If the method boundary is treated as “simple” rather than security-critical, teams may under-enforce caller identity, authorization checks, request validation, and rate limiting. A single request can then trigger unauthorized state changes, data exposure, or repeated side effects through retries and automation.

Impact: Compromise of a unary RPC method can enable direct abuse of high-value actions, such as object creation, record updates, or administrative operations. The result can be data integrity loss, privilege abuse, duplicate transactions, or a service-level denial of service.

Practitioner Guidance

Why practitioners should care: Unary RPC is often the default control plane for discrete service actions, so its contracts should be designed as if every call could change state, expose records, or trigger downstream workflows. The main governance question is whether each method is explicitly bounded, authorized, and safe to retry.

Common misunderstanding: Teams sometimes assume unary means “low risk” because it is only one request and one response. In practice, the security and reliability burden sits inside that single exchange, so the method still needs strong input validation, clear idempotency behavior, and precise ownership of each action.

Practitioner takeaway: Treat unary RPC as a crisp interface, not a casual one, and define its security and failure behavior with the same care you would give any state-changing API.

Related resources from NHI Mgmt Group

• Why do RDP, SMB, WinRM, and RPC create so much enterprise risk?
• How should security teams secure LDAP, RPC, and RDP without breaking operations?
• Who is accountable when RDP or RPC exposure leads to compromise?
• What breaks when SMB and RPC are not tightly segmented in Windows estates?