When you start learning system design, the hardest part is not the concepts themselves.

It is about finding clear explanations in one place.

That is why having a single guide that covers all the essentials is such a game-changer.

Therefore, I’ve designed this guide to cover 50 of the most important system design concepts.

Think of it as your one-stop reference for understanding how real systems scale, stay reliable, communicate, and handle data.

My goal is to walk you through fifty important ideas using short explanations and simple examples so everything clicks quickly.

If you are preparing for a system design interview, this guide is your go-to resource.

I. Core Architecture Principles

Vertical vs Horizontal Scaling

• Vertical scaling means upgrading a single machine, like adding more CPU, RAM, or faster storage.
• Horizontal scaling means adding more machines and spreading work across them.

Vertical is easier but hits hardware limits and becomes expensive.

Horizontal is harder because you need load balancing, stateless services, and shared storage.

Think of it this way: vertical is one superhero getting stronger, horizontal is building a team.

CAP Theorem

CAP Theorem says that in the presence of a network partition, a distributed system must choose between Consistency and Availability. Consistency means every user sees the same data at the same time.

Availability means the system always responds, even if the data might be slightly stale.

You cannot have perfect consistency and perfect availability when your network is broken, so you decide which one to sacrifice for your use case.

PACELC Theorem

PACELC extends CAP and says: if there is a Partition, choose Availability or Consistency; Else choose Latency or Consistency.

Even when the network is fine, you still trade off slow but consistent reads vs fast but eventually consistent reads. Systems that sync across regions often pay in latency to keep strong consistency.

It explains why some databases are fast but slightly stale, while others are slower but always accurate.

 

ACID vs BASE

ACID is about strict, reliable transactions: Atomicity, Consistency, Isolation, Durability. It suits financial systems, inventory, and anything where mistakes are very costly.

BASE stands for Basically Available, Soft state, Eventual consistency and is used in large distributed systems that need to stay up and respond quickly.

BASE systems might show temporary inconsistencies but fix themselves over time.

In practice, many architectures combine both, using ACID for core money flows and BASE for things like feeds and analytics.

Throughput vs Latency

• Throughput is how many requests your system can handle per second.
• Latency is how long a single request takes from start to finish.

You can often increase throughput by doing more work in parallel, but that may increase latency if queues build up.

Think of a restaurant that takes many orders at once but makes customers wait longer. Good system design tries to balance both: enough throughput for peak load but low latency for a smooth user experience.

Amdahl’s Law

Amdahl’s Law says that the speedup from parallelization is limited by the part that cannot be parallelized.

If 20 percent of your system is always sequential, no amount of extra machines will fix that bottleneck.

Let me break it down.

If your request always has to hit a single master database, that master will cap your performance. This law reminds you to hunt for bottlenecks instead of just adding more servers.

 

Strong vs Eventual Consistency

• Strong consistency means all users see the same data immediately after a write.
• Eventual consistency means updates spread over time and nodes may briefly disagree.

Strong consistency is easier to reason about but usually slower and less available under failures.

Eventual consistency is great for large-scale systems like timelines or counters where perfect freshness is not critical.

The key is to choose the model that matches the user experience you need.

Stateful vs Stateless Architecture

• A stateful service remembers user context between requests, often storing session data locally.
• A stateless service treats every request as new, relying on external stores like caches or databases for any state.

Stateless services are easier to scale horizontally because any instance can handle any request.

Stateful systems can be simpler to code but harder to load balance and fail over.

In modern cloud systems, we try to push state into databases and keep services as stateless as possible.

Microservices vs Monoliths

A monolith is a single application that contains many features in one deployable unit.

Microservices split features into separate services that communicate over the network.

Microservices help teams work independently and scale different parts separately, but introduce complexity around communication, debugging, and data consistency.

Monoliths are simpler to start with and often fine up to a certain scale. Here is the tricky part.

Many great systems start as monoliths and gradually evolve into microservices when the pain is real.

Serverless Architecture

Serverless lets you run small functions in the cloud without managing servers directly. You pay only when your code runs, and the platform handles scaling and infrastructure for you.

It is ideal for event-driven workloads such as webhooks, background jobs, or light APIs with spiky traffic.

The tradeoff is less control over long-running tasks, cold starts, and sometimes a higher cost at very high volumes.

Think of serverless as “functions as a service,” perfect for glue code and lightweight services.

II. Networking and Communication

Load Balancing

Load balancing spreads incoming traffic across multiple servers so no single server gets overloaded. It improves both reliability and performance, since a single server’s failure does not bring down the entire system.

Load balancers can be hardware devices or software services. They often support health checks so they stop sending traffic to unhealthy instances.

From an interview point of view, they are your first building block when scaling horizontally.

Load Balancing Algorithms

Common load balancing algorithms include Round Robin, Least Connections, and IP Hash.

• Round Robin cycles through servers in order and is simple to implement.
• Least Connections sends traffic to the server with the fewest active connections, which helps when requests vary in length.
• IP Hash uses a hash of the client IP so the same user usually goes to the same server, which helps with simple session stickiness.

Picking the right algorithm affects fairness, resource usage, and user experience.

Reverse Proxy vs Forward Proxy

• A reverse proxy sits in front of servers and represents them to clients. It hides the inner topology, can do TLS termination, caching, compression, and routing.
• A forward proxy sits in front of clients and represents them to the outside world, often for security, caching, or content filtering.

 

Think of a reverse proxy as the reception desk of a company that hides all the internal rooms, and a forward proxy as a gateway your laptop must pass through to reach the internet.

Knowing the difference helps when you talk about API gateways and corporate proxies.

API Gateway

An API gateway is a special reverse proxy that acts as a single entry point for all API calls in a microservices system. It handles routing to the right service, rate limiting, authentication, logging, and sometimes response shaping.

This reduces complexity on the client side, since clients only talk to a single endpoint.

If you put too much logic in the gateway, it can become a bottleneck or a mini monolith of its own. Good designs keep it focused and thin.

CDN (Content Delivery Network)

A CDN is a network of geographically distributed servers that cache static content like images, videos, and scripts closer to users.

When a user requests content, they are routed to the nearest CDN node, which greatly reduces latency. This also offloads traffic from your origin servers, improving scalability and resilience.

CDNs are essential for global applications and front-end performance.

Think of them as “local copies” of your website’s heavy files sprinkled around the world.

DNS (Domain Name System)

DNS maps human readable domain names to IP addresses.

When you type a website name, your device queries DNS to find the numeric address of the server.

has multiple layers of caching, so responses are fast after the first lookup. It can also be used to perform simple load balancing by returning different IPs for the same name.

Understanding DNS helps you reason about why name changes take time to propagate and why some outages are caused by misconfigured DNS.

TCP vs UDP

• TCP is a reliable, connection-oriented protocol. It guarantees ordered, error checked delivery by using acknowledgments and retries.
• UDP is connectionless and does not guarantee delivery or order, which makes it much faster and lighter.

TCP suits APIs, web pages, and file transfers where accuracy matters.

UDP works well for real time applications like video calls or games where occasional packet loss is acceptable.

Think of TCP as registered mail and UDP as quick postcards.

HTTP/2 and HTTP/3 (QUIC)

• HTTP/2 introduced multiplexing, which lets multiple requests share a single TCP connection, reducing overhead. It also brought features like header compression and server push.
• HTTP/3 runs over QUIC, which is built on UDP and improves connection setup time and performance on unreliable networks. These versions mainly aim to reduce latency and better use modern network conditions.

For you as an engineer, the key idea is: fewer connection setups and better use of a single connection.

gRPC vs REST

• REST typically uses HTTP with JSON and focuses on resources like /users or /orders. It is simple, human-readable, and widely used for public APIs.
• gRPC uses HTTP/2 and binary encoded messages (protobuf), which are smaller and faster over the wire. It also supports bidirectional streaming and strong typing.

In microservices, gRPC is often preferred for service-to-service calls, while REST is common for external clients.

Use REST when readability and compatibility matter, gRPC when performance and contracts matter.

WebSocket and Server-Sent Events (SSE)

WebSockets create a full-duplex connection where client and server can send messages to each other at any time.

SSE allows the server to push events to the client over a one way channel using HTTP.

WebSockets are great for chats, multiplayer games, and live collaboration.

SSE is simpler and fits cases like live score updates or notifications, where only the server needs to push updates.

Both solve real-time communication problems that plain HTTP cannot handle well.

Long Polling

Long polling is a technique where the client sends a request and the server holds it open until there is new data or a timeout.

When the response comes back, the client immediately opens another request. This simulates real time updates over plain HTTP without special protocols.

It is less efficient than WebSockets but easier to implement and works through most proxies and firewalls.

Think of it as asking “anything new?” and waiting quietly until there is an answer.

Gossip Protocol

A gossip protocol lets nodes in a distributed system share information by periodically talking to random peers.

Over time, information spreads like gossip in a social group until everyone has roughly the same view. It is used to share membership, health status, or configuration in a fault tolerant way.

The protocol is eventually consistent and does not rely on a central authority. This makes it ideal for large clusters where nodes frequently join and leave.

III. Database and Storage Internals

Sharding (Data Partitioning)

Sharding splits data across multiple machines, each holding a subset of the data. Common strategies include range-based sharding, hash-based sharding, and directory-based sharding.

The main goal is to scale storage and throughput by avoiding a single giant database node.

The tricky part is choosing a shard key that avoids hot spots where one shard gets most of the traffic. Once you shard, moving data between shards (resharding) becomes an important operational challenge.

Replication Patterns (Master Slave, Master Master)

Replication means keeping multiple copies of data on different nodes.

• In master slave (or primary replica), one node handles writes and replicates changes to others that serve reads.
• In master master (multi-primary), multiple nodes accept writes and reconcile conflicts.

Replication improves read performance and availability, but makes consistency harder, especially when writes go to multiple nodes.

In interviews, expect to talk about how replication lag affects reads and how failover works when a master dies.

Consistent Hashing

Consistent hashing is a technique to distribute keys across nodes in a way that minimizes data movement when nodes are added or removed.

Keys and nodes are placed on a logical ring, and each key belongs to the next node on the ring.

When a node joins or leaves, only a small portion of keys need to move. This property is very helpful in distributed caches and databases.

Think of it as a smooth mapping that does not get scrambled when the cluster size changes.

Database Indexing (B Trees, LSM Trees)

Indexes speed up queries by organizing data in a way that allows fast lookup.

B Trees are balanced trees that keep data sorted and let you find ranges efficiently, common in relational databases.

LSM Trees batch writes in memory and periodically flush them to disk, which makes writes very fast but reads more complex.

The tradeoff is write heavy vs read heavy workloads.

The key idea is that indexes are a separate structure that must be updated on every write, which is why too many indexes hurt insert performance.

Write Ahead Logging (WAL)

Write Ahead Logging records changes to a log before applying them to the main database.

If a crash happens in the middle of a transaction, the system can replay the log to restore a consistent state. WAL ensures durability and atomicity of transactions. It also allows techniques like replication from the log stream. Let me tell you why it is important.

Without WAL, a crash could leave your data in a half updated, corrupt state.

Normalization vs Denormalization

• Normalization organizes data into tables that reduce redundancy and dependencies, following rules like first normal form, second normal form, and so on. This avoids anomalies on updates and inserts.
• Denormalization intentionally duplicates data to speed up reads and reduce joins. In high scale systems, denormalization is common for read heavy paths, such as storing user names along with posts instead of joining every time.

The real skill is knowing where you can safely denormalize without breaking consistency.

Polyglot Persistence

Polyglot persistence means using multiple types of databases within the same system, each chosen for what it does best. You might use a relational database for transactions, a document store for logs, a key value store for caching, and a graph database for relationships.

Instead of forcing everything into one database, you pick the right tool for each job.

The tradeoff is more operational complexity and more knowledge required from the team.

Bloom Filters

A Bloom filter is a space efficient data structure that quickly answers “might this item be in the set?” with possible false positives but no false negatives. It uses multiple hash functions to set bits in a bit array when items are inserted.

To check membership, you test the same bits; if any bit is zero, the item is definitely not present.

Databases and caches use Bloom filters to avoid unnecessary disk lookups or cache misses.

Think of them as fast gatekeepers that say “definitely not” or “maybe.”

Vector Databases

Vector databases store and query vectors, which are numeric representations of data such as text, images, or audio. These vectors come from models like embeddings and allow similarity search, such as “find documents most similar to this one.”

Instead of exact equality comparisons, they use distance metrics like cosine similarity or Euclidean distance. This is essential for modern search, recommendation, and AI assistant systems.

In interviews, it is enough to know that vector databases support nearest neighbor search over high-dimensional data.

IV. Reliability and Fault Tolerance

Rate Limiting

Rate limiting controls how many requests a user, IP, or API key can make in a given time window. It protects your system from abuse, accidental traffic spikes, and runaway loops.

Common strategies include fixed window, sliding window, and token bucket.

Rate limits are often enforced at the API gateway or load balancer.

Think of them as safety brakes that keep shared resources from being overwhelmed.

Circuit Breaker Pattern

A circuit breaker monitors calls to a remote service and “opens” if there are too many failures.

When open, it immediately fails new requests instead of trying the broken service again.

After a cooldown period, it allows a few trial calls to see if the service has recovered and closes if they succeed. This pattern prevents cascading failures where one slow service drags down the entire system.

Here is the tricky part. Circuit breakers must be tuned carefully so they do not open too aggressively or too late.

Bulkhead Pattern

The bulkhead pattern isolates parts of a system so a failure in one area does not sink everything. This can mean separate connection pools, thread pools, or even entire service clusters for different features.

If one bulkhead is flooded with traffic, others keep working.

The name comes from ship bulkheads that contain flooding in one compartment.

In design discussions, using bulkheads shows you are thinking about fault isolation and blast radius.

Retry Patterns and Exponential Backoff

Retries help recover from transient errors like network timeouts or temporary overload.

Exponential backoff means each retry waits longer than the previous one, such as 1 second, 2 seconds, 4 seconds, and so on. This prevents your client from hammering a service that is already struggling.

Good retry policies also use jitter (small randomness) to avoid thundering herds.

Let me break it down.

Retries without backoff can make outages worse instead of helping.

Idempotency

An operation is idempotent if performing it multiple times has the same effect as performing it once.

For example, “set user status to active” is idempotent, while “increment account balance by 10” is not.

Idempotency is critical when systems use retries, because the same request may be sent more than once.

APIs often require idempotency keys on operations like payments to avoid double charging.

In interviews, always mention idempotency when you talk about at least once delivery or retries.

Heartbeat

A heartbeat is a periodic signal sent by a service or node to indicate that it is alive and healthy.

Monitoring systems or coordinators listen for heartbeats.

If they stop receiving them, they mark the node as down and trigger failover or scaling actions.

Heartbeats are simple but powerful tools for liveness detection. Think of them as the system’s “pulse checks.”

 

Leader Election (Paxos, Raft)

Leader election is the process of choosing a single node to act as a coordinator among many.

Algorithms like Paxos and Raft ensure that only one leader is chosen and that all nodes eventually agree on who that leader is.

The leader handles tasks like assigning work, managing metadata, or ordering writes. If the leader fails, a new one is elected automatically.

You do not need to memorize the math for interviews, but you should know that consensus algorithms power many critical systems like metadata stores and distributed logs.

Distributed Transactions (SAGA Pattern)

A distributed transaction spans multiple services or databases.

The SAGA pattern models such a transaction as a sequence of local steps with compensating actions for rollbacks.

Instead of locking everything like a single ACID transaction, each service performs its part and publishes an event. If something fails, compensating steps attempt to undo previous changes. This fits naturally with microservices and eventual consistency.

The tradeoff is more complex logic and the possibility of partial failures that must be handled gracefully.

Two Phase Commit (2PC)

Two Phase Commit is a protocol that tries to provide atomic transactions across multiple nodes.

• In the first phase, the coordinator asks all participants if they can commit.
• In the second phase, if everyone agrees, it tells them to commit; otherwise, it tells them to roll back.

2PC provides strong guarantees but can block if the coordinator fails, and it is expensive at scale due to locking.

In modern cloud systems, 2PC is often avoided for high throughput paths and replaced by patterns like SAGA.

V. Caching and Messaging

Caching

Caching stores frequently accessed data in a fast storage layer, usually memory, to reduce latency and backend load.

Common cache layers include in process caches, external key value stores, and CDNs. Caching is especially effective for read heavy workloads and expensive computations.

Here is the tricky part. Stale data and invalidation make caching harder than it first appears.

As the saying goes, cache invalidation is one of the hard problems in computer science.

Caching Strategies (Cache Aside, Write Through, etc.)

• Cache aside means the application reads from the cache, and on a miss, loads from the database and writes to the cache.
• Write through writes to the cache and database at the same time, ensuring cache and source are always in sync.
• Write back writes to the cache first and flushes to the database later, which is fast but risky if the cache fails.

Each strategy balances freshness, complexity, and performance differently.

Interviewers love when you mention which strategy you would pick for a given scenario.

Cache Eviction Policies (LRU, LFU)

Cache eviction policies decide which items to remove when the cache is full.

• LRU (Least Recently Used) evicts items that have not been accessed recently, assuming recent items are more likely to be used again.
• LFU (Least Frequently Used) evicts items that are rarely accessed, focusing on long term popularity.

Some systems use random, FIFO, or advanced algorithms.

The key idea is that cache space is limited, so you want to keep the most valuable items in memory.

Message Queues (Point to Point)

A message queue allows one component to send messages to another without needing both to be online at the same time.

In a point to point model, messages in a queue are consumed by one receiver and then removed. This decouples sender and receiver so they can scale and fail independently.

Queues are great for background jobs, email sending, and processing heavy tasks asynchronously.

Think of them as a todo list shared between services.

Pub Sub (Publish Subscribe)

In pub sub, publishers send messages to topics, not directly to consumers.

Subscribers listen to topics they care about and receive copies of relevant messages. This enables broadcast style communication and loose coupling between producers and consumers.

Multiple services can react to the same event in different ways, such as logging, analytics, and notifications.

In interviews, pub sub often appears in event driven designs like activity feeds or event sourcing.

Dead Letter Queues

A dead letter queue stores messages that could not be processed successfully after several attempts.

Instead of retrying forever and blocking the main queue, these messages are moved aside.

Engineers can inspect the dead letter queue to debug issues, fix data, or replay messages later. This pattern improves resiliency and keeps your system from getting stuck on “poison messages.”

Think of it as a holding area for problematic jobs.

VI. Observability and Security

Distributed Tracing

Distributed tracing tracks a single request as it flows through multiple services. Each service adds a trace ID and span information so you can reconstruct the full path of a request. This is extremely helpful when debugging slow responses or failures in microservice architectures.

Without tracing, you just see errors in isolation. With it, you see the whole story across services, queues, and databases.

SLA vs SLO vs SLI

An SLA (Service Level Agreement) is an external promise to customers, such as “99.9 percent uptime per month.”

An SLO (Service Level Objective) is an internal target that engineers aim to meet, usually stricter than the SLA. An SLI (Service Level Indicator) is the actual measured metric, like real uptimes or request success rates.

Think of SLA as the contract, SLO as the goal, and SLI as the scoreboard.

In interviews, using these terms correctly shows maturity in thinking about reliability.

OAuth 2.0 and OIDC

OAuth 2.0 is a framework for delegated authorization. It lets users grant an application limited access to their resources without sharing passwords.

OIDC (OpenID Connect) builds on OAuth 2.0 to add authentication, letting clients verify who the user is and get user identity information. This is the basis of many “Login with X” flows.

The key idea is that an authorization server issues tokens that clients and APIs can trust.

TLS/SSL Handshake

TLS/SSL secures communication between client and server by encrypting data in transit.

During the handshake, the client and server agree on encryption algorithms, exchange keys securely, and verify certificates.

Once the handshake completes, all subsequent data is encrypted and safe from eavesdropping. This is what puts the little lock icon in your browser.

Without TLS, anyone on the network could read or modify sensitive traffic.

Zero Trust Security

Zero Trust is a security model that says: “Never trust, always verify.” It assumes that threats can exist both outside and inside the network.

Every request must be authenticated, authorized, and encrypted, even if it comes from within your data center or VPC. Access is granted based on identity, device posture, and context, not just on being “inside the firewall.”

In modern architectures, Zero Trust is becoming the default approach to secure system design.

Reference

• Complete Roadmap to Learn System Design (free)
• Grokking the System Design Interview
• System Design Crash Course (Free)

Key Takeaways

• System design is mostly about understanding trade-offs: consistency vs. availability, latency vs. throughput, simplicity vs. flexibility.
• Scaling is not just “add more servers.” You must think about load balancing, sharding, replication, and bottlenecks.
• Reliability patterns like rate limiting, circuit breakers, retries, and bulkheads exist because failures are normal in distributed systems.
• Caching, queues, and pub-sub are your best friends for performance and decoupling, but they introduce new challenges around consistency and ordering.
• Observability and security concepts such as tracing, SLIs, OAuth, TLS, and Zero Trust are essential for systems that are not just fast but also safe and debuggable.

Fonte: https://designgurus.substack.com/p/50-system-design-concepts-for-beginners

 

Executive Summary

This document synthesizes 50 fundamental concepts in system design, drawing from a comprehensive guide on the subject. The core insight is that effective system design is an exercise in managing trade-offs, particularly between consistency and availability, latency and throughput, and simplicity versus flexibility. Successful scaling extends beyond merely adding servers; it necessitates a deep understanding of load balancing, data sharding, replication, and bottleneck identification.

Reliability in distributed systems is not an accident but a deliberate architectural choice, achieved through patterns like rate limiting, circuit breakers, retries, and bulkheads, which are designed to handle expected failures gracefully. Performance and decoupling are significantly enhanced by tools such as caching, message queues, and publish-subscribe models, though these introduce their own complexities regarding data consistency and message ordering. Finally, modern systems must be built with observability and security as primary concerns, incorporating distributed tracing, service level indicators (SLIs), robust authentication (OAuth/OIDC), data-in-transit encryption (TLS), and a Zero Trust security posture to ensure they are not only performant but also safe, secure, and debuggable.

Press enter or click to view image in full size

I. Core Architecture Principles

This section outlines the foundational principles and architectural choices that govern how systems are structured, scaled, and managed.

Press enter or click to view image in full size

Vertical vs. Horizontal Scaling

• Vertical Scaling: Involves upgrading a single machine by adding more CPU, RAM, or faster storage. It is simpler to implement but is constrained by hardware limits and becomes progressively more expensive. The analogy provided is a single superhero getting stronger.
• Horizontal Scaling: Involves adding more machines and distributing the workload across them. While more complex, requiring load balancing, stateless services, and shared storage, it offers greater scalability. The analogy is building a team of superheroes.

CAP Theorem

• The CAP Theorem states that in a distributed system experiencing a network partition, it is impossible to simultaneously guarantee both Consistency and Availability.
• Consistency: Every user sees the same data at the same time.
• Availability: The system always provides a response, even if the data may be temporarily out of date.
• A system must choose which of these two guarantees to sacrifice during a network failure.

PACELC Theorem

• PACELC is an extension of the CAP theorem. It posits that: if there is a Partition, a system must choose between Availability and Consistency; Else (in normal operation), it must choose between Latency and Consistency.
• This theorem clarifies that even without network failures, systems face a trade-off between fast, eventually consistent reads (lower latency) and slower, strongly consistent reads (higher consistency).

Press enter or click to view image in full size

ACID vs. BASE

• ACID (Atomicity, Consistency, Isolation, Durability): A set of properties for strict, reliable database transactions. It is essential for systems where data integrity is paramount, such as financial or inventory management systems.
• BASE (Basically Available, Soft state, Eventual consistency): An alternative model for large-scale distributed systems that prioritize high availability and rapid response times. BASE systems may exhibit temporary inconsistencies that resolve over time.
• Many modern architectures employ a hybrid approach, using ACID for critical transactional flows and BASE for less critical functions like activity feeds or analytics.

Throughput vs. Latency

• Throughput: The number of requests a system can process per unit of time (e.g., requests per second).
• Latency: The time taken to process a single request from start to finish.
• These two metrics are often in opposition; increasing throughput by processing more work in parallel can lead to queue buildup and increased latency for individual requests. Effective system design seeks to balance both for an optimal user experience.

Amdahl’s Law

• This law states that the potential performance improvement from parallelization is limited by the portion of the system that must remain sequential.
• If a part of a process is inherently non-parallelizable (e.g., a final step that must hit a single master database), that part will become the ultimate bottleneck, capping overall performance regardless of how many more resources are added.

Press enter or click to view image in full size

Strong vs. Eventual Consistency

• Strong Consistency: Guarantees that all users see the same data immediately following a write operation. It is simpler to reason about but can be slower and less available during failures.
• Eventual Consistency: Allows for a brief period where different nodes in a distributed system may have different versions of the data. Updates propagate through the system over time. This model is suited for large-scale applications where immediate consistency is not critical, such as social media timelines.

Stateful vs. Stateless Architecture

• Stateful Service: Remembers user-specific context or session data between requests, often storing it locally. This can simplify application logic but complicates scaling, load balancing, and failover.
• Stateless Service: Treats every request as new and self-contained, relying on external storage (e.g., databases, caches) for any required state. Stateless services are easier to scale horizontally, as any server instance can handle any request.

Microservices vs. Monoliths

• Monolith: A single, unified application where all features are contained within one deployable unit. Monoliths are simpler to develop and deploy initially.
• Microservices: An architectural style that splits application features into small, independent services that communicate over a network. This approach allows teams to work independently and scale different components separately but introduces complexity in communication, debugging, and data management.
• A common evolutionary path is to start with a monolith and gradually break it apart into microservices as the system grows and its pain points become clear.

Serverless Architecture

• Also known as “Functions as a Service” (FaaS), serverless architecture allows developers to run small, event-driven functions in the cloud without managing the underlying server infrastructure.
• Advantages: Pay-per-use pricing and automatic scaling handled by the cloud provider. Ideal for workloads with spiky traffic like webhooks, background jobs, or simple APIs.
• Trade-offs: Can involve “cold starts” (initial latency), less control over long-running tasks, and potentially higher costs at sustained high volumes.

II. Networking and Communication

This section covers the protocols, patterns, and components used to manage traffic and facilitate communication between different parts of a system.

Press enter or click to view image in full size

Load Balancing

• Function: Distributes incoming network traffic across multiple servers to prevent any single server from becoming a bottleneck.
• Benefits: Improves both system performance and reliability, as the failure of one server does not bring down the entire application.
• Implementation: Can be a hardware appliance or a software service. Load balancers typically use health checks to avoid sending traffic to unresponsive servers.

Load Balancing Algorithms

• Round Robin: Distributes requests to servers sequentially in a circular order. Simple but does not account for server load or request complexity.
• Least Connections: Sends new requests to the server with the fewest active connections. This is effective when requests have varying completion times.
• IP Hash: Uses a hash of the client’s IP address to determine which server receives the request. This provides a basic form of “session stickiness,” ensuring a user is consistently routed to the same server.

Reverse Proxy vs. Forward Proxy

• Reverse Proxy: Sits in front of a group of servers, intercepting client requests and forwarding them to the appropriate backend server. It can handle tasks like TLS termination, caching, compression, and routing, while hiding the internal network topology.
• Forward Proxy: Sits in front of clients, forwarding their requests to the internet. It is often used for security, content filtering, or caching within a corporate or private network.

API Gateway

• An API Gateway is a specialized reverse proxy that serves as the single entry point for all API calls in a microservices architecture.
• Responsibilities: Handles routing, rate limiting, authentication, logging, and response transformation.
• Benefit: Simplifies the client-side by providing a single, unified endpoint.
• Risk: Can become a bottleneck or a “mini monolith” if too much business logic is embedded within it.

Press enter or click to view image in full size

CDN (Content Delivery Network)

• A CDN is a geographically distributed network of proxy servers that cache static assets (images, videos, CSS, JavaScript) close to end-users.
• Function: When a user requests content, the request is routed to the nearest CDN node, dramatically reducing latency.
• Benefits: Offloads traffic from origin servers, improves front-end performance, and increases application scalability and resilience.

DNS (Domain Name System)

• DNS is the system that translates human-readable domain names (e.g., www.example.com) into machine-readable IP addresses (e.g., 192.0.2.1).
• It operates with multiple layers of caching for fast lookups and can be used for basic load balancing by returning different IP addresses for the same domain name.

TCP vs. UDP

• TCP (Transmission Control Protocol): A connection-oriented protocol that guarantees reliable, ordered, and error-checked delivery of data. It is suitable for applications where data integrity is critical, such as web browsing, file transfers, and APIs.
• UDP (User Datagram Protocol): A connectionless protocol that is faster and has less overhead than TCP but does not guarantee delivery or order. It is well-suited for real-time applications like video streaming and online gaming, where speed is more important than perfect reliability.

Press enter or click to view image in full size

HTTP/2 and HTTP/3 (QUIC)

• HTTP/2: Improved upon HTTP/1.1 by introducing request multiplexing over a single TCP connection, header compression, and server push, all aimed at reducing latency.
• HTTP/3: Further enhances performance by running over QUIC (a transport protocol built on UDP), which reduces connection setup time and performs better on unreliable networks with packet loss.

gRPC vs. REST

• REST: An architectural style that typically uses HTTP and JSON. It is resource-oriented, human-readable, and widely adopted for public-facing APIs.
• gRPC: A high-performance RPC framework that uses HTTP/2 for transport and Protocol Buffers (protobuf) for binary serialization. It is smaller and faster than REST/JSON and supports features like bidirectional streaming, making it a popular choice for internal service-to-service communication in microservices architectures.

WebSocket and Server-Sent Events (SSE)

• WebSockets: Provide a persistent, full-duplex (two-way) communication channel between a client and a server over a single TCP connection. Ideal for real-time interactive applications like chat, collaborative editing, and multiplayer games.
• SSE: A simpler protocol that allows a server to push updates to a client over a one-way channel using standard HTTP. It is suitable for use cases where only the server needs to send data, such as live news feeds or stock tickers.

Long Polling

• A technique that simulates server-push functionality over standard HTTP. The client sends a request to the server, which holds the connection open until it has new data to send or a timeout occurs. Upon receiving a response, the client immediately initiates a new request.
• It is less efficient than WebSockets but is easier to implement and compatible with older proxies and firewalls.

Gossip Protocol

• A decentralized communication protocol where nodes in a distributed system share information by periodically exchanging data with random peers.
• Information propagates through the network “like gossip,” ensuring that all nodes eventually converge on a consistent view without a central coordinator. It is highly fault-tolerant and used for service discovery, health monitoring, and state dissemination in large clusters.

III. Database and Storage Internals

This section details the techniques and technologies used to manage data at scale, focusing on partitioning, replication, indexing, and transactional integrity.

Press enter or click to view image in full size

Sharding (Data Partitioning)

• Definition: The process of splitting a large database into smaller, more manageable pieces called shards, with each shard residing on a separate machine.
• Goal: To scale database storage capacity and throughput horizontally.
• Strategies: Include range-based, hash-based, and directory-based sharding.
• Challenge: Choosing an effective shard key is crucial to avoid “hot spots,” where one shard receives a disproportionate amount of traffic.

Replication Patterns

• Definition: The practice of keeping multiple copies of data on different nodes to improve availability and read performance.
• Master-Slave (Primary-Replica): One node (the master) handles all write operations, which are then replicated to one or more slave nodes that can serve read requests.
• Master-Master (Multi-Primary): Multiple nodes can accept write operations, and they synchronize data with each other. This increases write availability but introduces complexity in resolving write conflicts.

Consistent Hashing

• A hashing technique designed to minimize data re-shuffling when nodes are added to or removed from a distributed system (like a cache or database).
• Both keys and nodes are mapped to a logical ring. A key is assigned to the first node encountered moving clockwise on the ring. This ensures that when a node is added or removed, only a small, adjacent set of keys needs to be remapped.

Press enter or click to view image in full size

Database Indexing

• Purpose: Indexes are data structures that improve the speed of data retrieval operations on a database table at the cost of slower writes and increased storage space.
• B-Trees: Balanced tree structures common in relational databases. They keep data sorted and are efficient for both point lookups and range queries.
• LSM (Log-Structured Merge) Trees: Optimize for high write throughput by batching writes in memory and periodically flushing them to sorted files on disk. Reads can be more complex as they may need to check multiple files.

Write-Ahead Logging (WAL)

• A standard method for ensuring data durability and atomicity. Before any changes are applied to the database itself, they are first recorded in a sequential log file on durable storage.
• In the event of a system crash, the database can replay the log to recover to a consistent state, preventing data corruption from partially completed transactions.

Normalization vs. Denormalization

• Normalization: The process of organizing data in a relational database to minimize redundancy and improve data integrity by dividing larger tables into smaller, well-structured ones.
• Denormalization: The intentional introduction of redundancy by duplicating data across multiple tables. This is often done in high-scale systems to optimize read performance by avoiding expensive join operations.

Press enter or click to view image in full size

Polyglot Persistence

• The practice of using multiple different database technologies within a single application, choosing the best tool for each specific job.
• An application might use a relational database for transactional data, a document store for unstructured content, a key-value store for caching, and a graph database for relationship-heavy data. This adds operational complexity but allows for optimized performance and functionality.

Bloom Filters

• A probabilistic, space-efficient data structure used to test whether an element is a member of a set.
• It can produce false positives (it might incorrectly say an element is in the set) but never false negatives (if it says an element is not in the set, it is definitively not).
• They are used to avoid expensive lookups for items that are likely not present, such as checking a cache before querying a database.

Vector Databases

• Specialized databases designed to store, manage, and query high-dimensional vector embeddings, which are numerical representations of data like text or images.
• They excel at similarity searches using distance metrics (e.g., cosine similarity), enabling applications like semantic search, recommendation engines, and other AI-powered features.

IV. Reliability and Fault Tolerance

This section explores patterns and strategies for building resilient systems that can withstand and recover from failures.

Press enter or click to view image in full size

Rate Limiting

• Function: Controls the frequency of requests a user or client can make to an API or service within a specific time window.
• Purpose: Protects backend services from abuse, accidental overload, and denial-of-service attacks.
• Strategies: Common algorithms include fixed window, sliding window, and token bucket.

Circuit Breaker Pattern

• A pattern that prevents an application from repeatedly trying to execute an operation that is likely to fail.
• Mechanism: A circuit breaker monitors calls to a downstream service. If the number of failures exceeds a threshold, the breaker “opens,” and subsequent calls fail immediately without attempting to contact the service. After a timeout, the breaker enters a “half-open” state to test if the service has recovered.

Bulkhead Pattern

• An application design pattern that isolates system elements into pools so that if one fails, the others can continue to function.
• Named after the partitioned sections of a ship’s hull, this pattern can be implemented by using separate thread pools or connection pools for different services, preventing a failure in one area from cascading and taking down the entire system.

Press enter or click to view image in full size

Retry Patterns and Exponential Backoff

• Retries: A mechanism for handling transient failures by automatically re-attempting a failed operation.
• Exponential Backoff: A crucial enhancement to retries where the delay between attempts increases exponentially (e.g., 1s, 2s, 4s). This prevents a client from overwhelming a struggling service with rapid-fire retries. Adding “jitter” (a small random delay) is also recommended to avoid synchronized retry storms.

Idempotency

• An operation is idempotent if it can be performed multiple times with the same result as performing it once. For example, setting a value is idempotent, while incrementing a counter is not.
• Idempotency is critical in distributed systems where network failures can lead to retries, ensuring that a re-sent request does not cause unintended side effects like duplicate transactions.

Heartbeat

• A periodic signal sent from a node or service to a monitoring system to indicate it is alive and functioning correctly.
• If the monitoring system stops receiving heartbeats from a node, it can assume the node has failed and trigger a failover process.

Leader Election

• The process in a distributed system by which a single node is chosen to assume a special role, such as a coordinator or primary for writes.
• Consensus algorithms like Paxos and Raft provide fault-tolerant mechanisms to ensure that all nodes agree on a single leader and can elect a new one if the current leader fails.

Distributed Transactions (SAGA Pattern)

• The SAGA pattern is a way to manage data consistency across multiple microservices without using traditional two-phase commit locks.
• A transaction is structured as a sequence of local transactions, each with a corresponding compensating action. If any step fails, the compensating actions are executed in reverse order to undo the preceding steps, thus maintaining overall consistency.

Two-Phase Commit (2PC)

• A protocol used to achieve atomic transactions across multiple distributed nodes.
• Phase 1 (Prepare): A coordinator asks all participating nodes if they are ready to commit.
• Phase 2 (Commit/Abort): If all participants vote “yes,” the coordinator instructs them to commit. If any vote “no” or fail to respond, the coordinator instructs all to roll back.
• 2PC provides strong consistency but is prone to blocking if the coordinator fails and can be a performance bottleneck.

V. Caching and Messaging

This section describes key technologies for improving performance and decoupling system components through in-memory data storage and asynchronous communication.

Caching

• Definition: Storing copies of frequently accessed data in a fast, temporary storage layer (typically memory) to serve future requests more quickly.
• Benefits: Reduces latency for end-users and decreases the load on backend systems like databases.
• Challenge: The primary difficulty with caching is “cache invalidation” — ensuring that stale data is removed or updated when the source data changes.

Press enter or click to view image in full size

Caching Strategies

• Cache-Aside: The application is responsible for managing the cache. It first checks the cache; on a miss, it reads data from the database, then writes that data into the cache for future requests.
• Write-Through: The application writes data to the cache and the database simultaneously. This ensures the cache is always consistent with the database but adds latency to write operations.
• Write-Back: The application writes data only to the cache, which acknowledges the write immediately. The data is then flushed to the database asynchronously at a later time. This offers very low write latency but risks data loss if the cache fails before the data is persisted.

Cache Eviction Policies

• LRU (Least Recently Used): When the cache is full, the item that has been accessed least recently is removed.
• LFU (Least Frequently Used): When the cache is full, the item that has been accessed the fewest times is removed.
• Other policies include FIFO (First-In, First-Out) and random replacement. The choice of policy depends on the application’s access patterns.

Press enter or click to view image in full size

Message Queues (Point-to-Point)

• A message queue enables asynchronous communication between services. A “producer” sends a message to a queue, and a “consumer” retrieves it for processing at a later time.
• Each message is typically processed by only one consumer. This pattern decouples the sender and receiver, allowing them to operate and scale independently. It is commonly used for background jobs.

Pub/Sub (Publish-Subscribe)

• A messaging pattern where “publishers” send messages to a “topic” without knowledge of the “subscribers.” Any number of subscribers can listen to a topic and receive a copy of every message sent to it.
• This enables one-to-many, broadcast-style communication and is central to event-driven architectures.

Dead Letter Queues (DLQ)

• A secondary queue used to store messages that could not be processed successfully after a certain number of retries.
• Moving “poison messages” to a DLQ prevents them from blocking the main processing queue. Engineers can later inspect the DLQ to diagnose and resolve the underlying issues.

VI. Observability and Security

This section covers essential concepts for monitoring system health, understanding behavior, and implementing robust security measures.

Press enter or click to view image in full size

Distributed Tracing

• A method for monitoring and profiling applications, especially those built using a microservices architecture.
• It tracks a single request as it travels through multiple services, assigning a unique trace ID that allows developers to visualize the entire request path, identify bottlenecks, and debug cross-service issues.

SLA vs. SLO vs. SLI

• SLA (Service Level Agreement): A formal contract with a customer that defines the level of service they can expect, often with financial penalties for non-compliance (e.g., “99.9% uptime”).
• SLO (Service Level Objective): An internal target for system reliability that is stricter than the SLA. This is the goal that engineering teams strive to meet.
• SLI (Service Level Indicator): The actual, quantitative metric used to measure compliance with an SLO (e.g., the success rate of HTTP requests). The SLI is the “scoreboard” that measures performance.

OAuth 2.0 and OIDC

• OAuth 2.0: An authorization framework that allows a user to grant a third-party application limited access to their resources on another service without sharing their credentials.
• OIDC (OpenID Connect): A thin layer built on top of OAuth 2.0 that adds an authentication component. It allows an application to verify a user’s identity and obtain basic profile information. Together, they form the foundation of modern “Login with…” features.

TLS/SSL Handshake

• TLS (Transport Layer Security)/SSL (Secure Sockets Layer): Cryptographic protocols that provide secure communication over a computer network.
• The handshake is the initial process where the client and server establish a secure connection. During the handshake, they agree on an encryption cipher, exchange cryptographic keys, and authenticate the server via its digital certificate.

Zero Trust Security

• A security model based on the principle of “never trust, always verify.” It assumes that threats can originate from anywhere, both inside and outside the network perimeter.
• In a Zero Trust architecture, every request must be authenticated, authorized, and encrypted, regardless of its origin. Access is granted based on user identity and device posture, not on network location.

Press enter or click to view image in full size

You can think of system design like running a professional restaurant. Vertical scaling is buying a bigger stove, while horizontal scaling is hiring a whole team of chefs. Load balancing is the host at the front door assigning customers to different tables so no waiter is overwhelmed. A CDN is like having pre-made snacks available at local convenience stores so people don’t have to travel to your main kitchen for everything. Finally, Circuit Breakers are like a safety fuse in the kitchen: if one appliance starts smoking, it cuts the power immediately to that section so the whole restaurant doesn’t burn down.

Fonte: https://medium.com/@MaheshwariRishabh/50-core-system-design-concepts-6828ed73c2e8

System design interview performance is always a critical factor in validating whether a candidate can come up with scalable and efficient systems. Knowledge of major terminologies will definitely help in acing these. Below are the top 50 must-know system design interview terminologies that we will explain with definitions and working examples, along with additional resources for learning.

1. Scalability

• Definition: It is the ability of a system to support increased load by adding resources.
• Example: Addition of more servers to handle the increase in web traffic.
• Learn More: What is Scalability and How to Achieve it?

2. Load Balancer

• Definition: Dividing the incoming network traffic among multiple servers so that no one server processes a large amount of load.
• Example: Load balancing web traffic across multiple EC2 instances using the AWS Elastic Load Balancer(ELB) Service.
• Learn More: Understanding Load Balancer

3. Microservices

• Definition: It is an architectural pattern forcing the structuring of an application as a collection of loosely coupled services.
• Example: Breaking down a monolithic application into independent services responsible for user management, processing payments, and sending notifications.
• Learn More: What are Microservices?

4. CAP Theorem

• Definition: It states that at best, only two out of three guarantees can be gained in a distributed system: Consistency, Availability, and Partition Tolerance.
• Example: When to Trade Off Consistency for Availability — And Vice Versa — in Distributed Database Design.
• Learn More: Understanding CAP Theorem

5. Sharding

• Definition: It involves breaking down a large database into smaller pieces called shards for better management.
• Example: Sharding a user database based on geographic region.
• Learn More: Database Sharding Explained

6. Latency

• Definition: This gets defined as the time that it takes for data to travel from point A to point B.
• Example: Measuring the delay involved in message delivery through a chat application.
• Learn More: Latency explained!

7. Throughput

• Definition: A measure of the quantity of data a system processes in some timeframe
• Example: Requests processed by a web server in one second.
• Learn More: Throughput in Computer Networks

8. Cache

• Definition: Any hardware or software component that stores data to obviate future requests for the same data, serving It quickly.
• Example: Implementing Redis caching for repeated database queries.
• Learn More: Caching Explained

9. Content Delivery Network (CDN)

• Definition: A server system, geographically dispersed, that shows Web content to a user based on the geographical location from which he is accessing.
• Example: Using Cloudflare CDN for faster web page loading.
• Learn More: What is a CDN?

10. REST API

• Definition: a type of architectural style designed to build web services where data is accessed and manipulated using HTTP requests.
• Example: Designing the Social Media API by REST(Representational State Transfer) principles.
• Learn More: REST API Tutorial

11. GraphQL

• Definition: It is a language designed to query data, so it is much more powerful, efficient, and flexible than REST.
• Example: Using GraphQL to query user information in a single request.
• Learn More: GraphQL Introduction

12. ACID

• Definition: A set of properties ensuring reliable processing of database transactions. The properties are Atomicity, Consistency, Isolation, and Durability.
• Example: Ensuring that a banking transaction has ACID properties prevents corrupted data.
• Learn More: ACID Properties in Databases

13. BASE

• Definition: An alternate to ACID that emphasizes Availability and Partition tolerance over strict-Consistency. Basically Available, Soft state, Eventually consistent system.
• Example: Design of a highly available, eventually consistent NoSQL database.
• Learn More: BASE vs ACID

14. NoSQL

• Definition: A type of database designed to promote storage and retrieval of data modelled in ways other than the tabular relationships used in relational databases.
• Example: Using MongoDB for a document-based data store.
• Learn More: What is a NoSQL Database?

15. SQL

• Definition: It is the standard language used for storing, manipulating, and retrieving data in relational databases.
• Example: Writing SQL queries to get data back from a relational database.
• Learn More: SQL Tutorial

16. Database Indexing

• Definition: It is a data structure technique that allows quick searching and access to data from a database.
• Example: Create indexing on the column of User ID for searching speed enhancement.
• Learn More: Database Indexing

17. Replication

• Definition: A process of copying and maintaining database objects in a multitude of databases which make up a distributed database system.
• Example: It involves allowing a database to be highly available across different geographical locations using replication.
• Learn More: Database Replication

18. Failover

• Definition: A backup operational mode in which system component functions are taken over by other system components in case of loss of a primary system component.
• Example: Built-in automatic failovers to standby servers in the event of a server failure of your internet applications.
• Learn More: Failover Vs Disaster Recovery

19. API Gateway

• Definition: A server that sits at the front of an API, receiving API requests, applying throttling and security policies, and then forwarding them to back-end services.
• Example: Using AWS API Gateway to manage APIs.
• Learn More: What is an API Gateway?

20. Service Mesh

• Definition: A dedicated infrastructure layer for facilitating service-to-service communications between microservices.
• Example: Integrating Istio as a service mesh for the management of microservice interactions.
• Learn More: Introduction to Service Mesh

21. Serverless Computing

• Definition: A Cloud computing implementation that “dynamically allows for the allotment of machine resources by the cloud provider”.
• Example: Run backend code without any server provisioning at your end using AWS Lambda.
• Learn More: What is Serverless Computing?

22. Event-Driven Architecture

• Definition: A software architecture paradigm encouraging the generation, detection, and consumption of, and the reaction to, events in general.
• Example: Design a system with event communications between microservices using Apache Kafka.
• Learn More: Event-Driven Architecture

23. Monolithic Architecture

• Definition: A software architecture wherein all the elements are fitted into a single application and run as a single service.
• Example: Old traditional enterprise applications built as a single, large unit.
• Learn More: Monolithic vs Microservices Architecture

24. Distributed Systems

• Definition: A model wherein components located on networked computers communicate with each other and coordinate their actions by passing messages.
• Example: Designing a distributed file system like Hadoop.
• Learn More: Introduction to Distributed Systems

25. Message Queue

• Definition: This method allows asynchronous, service-to-service communication in both serverless and microservices architectures.
• Example: Using RabbitMQ to queue messages between services.
• Learn More: Message Queues Explained

26. Pub/Sub Model

• Definition: A messaging pattern in which senders (publishers) publish messages so abstractly that any one of them can end up being accessed by recipients without the sender having to even know the identity of the destination receivers (subscribers).
• Example: A notification system that uses Google Cloud Pub/Sub.
• Learn More: Pub/Sub Messaging

27. Data Partitioning

• Definition: Division of a database into smaller, manageable parts.
• Example: Partitioning a table in a database by date to allow super-fast query execution.
• Learn More: Database Partitioning

28. Horizontal Scaling

• Definition: Increasing the capacity by adding more machines or nodes within a system.
• Example: Adding more web servers to handle an increasing volume of user traffic.
• Learn More: Horizontal vs Vertical Scaling

29. Vertical Scaling

• Definition: Upgrading an already existing machine with more power in the form of a CPU or RAM.
• Example: Upgrading the RAM of a server so that it can handle more requests all at once.
• Learn More: Horizontal vs Vertical Scaling

30. Rate Limiting

• Definition: It means controlling the rate of traffic that the network interface controller is sending or receiving.
• Example: Throttling an API to prevent abusive behaviour.
• Learn More: Understanding Rate Limiting

31. Circuit Breaker Pattern

• Definition: A design pattern used in modern software development, applied to detect failures and encapsulate the logic of preventing a failure from constantly recurring.
• Example: Handling failed remote service calls using a circuit breaker in a microservice architecture.
• Learn More: Circuit Breaker Pattern

32. Data Consistency

• Definition: Ensuring that data is the same across multiple instances and is not corrupted.
• Example: Maintaining the consistency of user data through multiple replicas of a database.
• Learn More: Data Consistency Models

33. Eventual Consistency

• Definition: A model of consistency used in distributed computing toward the goal of high availability, stating that updates to a system will eventually propagate and be reflected by all nodes.
• Example: Amazon DynamoDB provides an eventually consistent model for the read operation.
• Learn More: Eventual Consistency

34. Strong Consistency

• Definition: A consistency model ensuring every read gets the most recent write on a given unit of data.
• Example: Using strong consistency in a financial transaction system.
• Learn More: Strong Consistency

35. Containerization

• Definition: Basically, this is whenever an application and its dependencies are encapsulated into a container to be run on any computational environment.
• Example: Using Docker to containerize the applications for deployment in various environments such as dev, test, prod etc.
• Learn More: What is Containerization?

36. Kubernetes

• Definition: An open-source platform that automates the process of application container deployment, scaling, and operation.
• Example: Run and deploy containerized applications using Kubernetes.
• Learn More: Kubernetes Documentation

37. Autoscaling

• Definition: Automatically adjusting the number of computational resources based on the user load.
• Example: Utilizing AWS EC2 Auto Scaling feature to dynamically adjust the number of instances.
• Learn More: Auto Scaling explained

38. Multi-Tenancy

• Definition: Architecture where a single instance of a software application serves multiple consumers/customers.
• Example: SaaS applications, such as Salesforce, utilize multi-tenancy in their service provision toward their different categories of customers.
• Learn More: Single Tenancy Vs Multi-Tenancy?

39. Load Shedding

• Definition: Backing off some demands or degrading services to maintain the health of the overall system under high load.
• Example: This will turn off all non-essential services during times of peak traffic.
• Learn More: Load Shedding

40. Idempotence

• Definition: A property for some mathematical and computer-science operations stating that it has the same effect if repeated more times than once.
• Example: An HTTP DELETE request is idempotent.
• Learn More: Idempotence in APIs

41. Quorum

• Definition: The minimum number of votes needed to commit a distributed transaction.
• Example: Basically, quorum-based replication ensures that consistency exists in the distributed database.
• Learn More: Quorum Systems

42. Orchestration

• Definition: A pattern of service interaction where a central coordinator controls the interaction between services.
• Example: Using a workflow engine to manage some multi-step business process.
• Learn More: Orchestration

43. Choreography

• Definition: A service interaction pattern in which every service is self-contained and interacts with others through events; there will not be any coordinator or orchestrator.
• Example: Microservices communicating through an event bus in a choreography pattern.
• Learn More: Choreography vs. Orchestration

44. Service Registry

• Definition: A database that keeps track of instances of microservices.
• Example: Using the Eureka service registry in a microservice architecture.
• Learn More: Service Registry and Discovery

45. API Rate Limiting

• Definition: It means controlling how many requests a client can make against an API within a certain timeframe.
• Example: Limiting requests to an API to 100 per minute to prevent abuse.
• Learn More: API Rate Limiting

46. Data Warehouse

• Definition: A system that helps in the generation of reports and business data analytics; the hub of Business Intelligence.
• Example: Amazon Redshift can be implemented in data warehousing.
• Learn More: Understanding Data Warehouse?

47. Data Lake

• Definition: A system or repository where data is kept in native/raw format, generally as object blobs or files.
• Example: Petabyte scaling for storing and managing structured and unstructured data in a data lake.
• Learn More: Data Lake

48. OLAP

• Definition: Online Analytical Processing : The software category that allows the analysis of data kept in a database.
• Example: Use of the OLAP cubes for pointy analytical and arbitrary queries.
• Learn More: OLAP Explained

49. OLTP

• Definition: Online Transaction Processing: a class of systems that manage transaction-oriented applications.
• Example: Using OLTP systems for transaction data management, as in banking systems etc.
• Learn More: OLTP Explained

50. Big Data

• Definition: Large, complex data sets that cannot be efficiently managed by conventional data-processing software in the best of cases.
• Example: Analyzing social media interactions to predict fashion trends.
• Learn More: Introduction to Big Data

Keep in mind that it’s all about continuous learning and practice as you go further in system design. You can work with the resources, get involved in the discussions, and practice these concepts in your projects. The resources and discussions will expose you to the vocabulary and usages of the concept.

I. Princípios Essenciais de Arquitetura

Escala vertical versus horizontal

• Escalabilidade vertical significa atualizar uma única máquina, como adicionar mais CPU, RAM ou armazenamento mais rápido.
• A escalabilidade horizontal significa adicionar mais máquinas e distribuir o trabalho entre elas.

A instalação vertical é mais fácil, mas atinge os limites do hardware e se torna cara.

A arquitetura horizontal é mais complexa porque exige balanceamento de carga, serviços sem estado e armazenamento compartilhado.

Pense da seguinte forma: na vertical, um super-herói fica mais forte; na horizontal, a formação de uma equipe.

Teorema CAP

O Teorema CAP afirma que, na presença de uma partição de rede, um sistema distribuído deve escolher entre Consistência e Disponibilidade . Consistência significa que todos os usuários veem os mesmos dados ao mesmo tempo.

Disponibilidade significa que o sistema sempre responde, mesmo que os dados estejam ligeiramente desatualizados.

Não é possível ter consistência perfeita e disponibilidade perfeita quando sua rede está inoperante, então você decide qual delas sacrificar para o seu caso de uso.

Teorema PACELC

O PACELC amplia o CAP e afirma: se houver uma partição, escolha Disponibilidade ou Consistência; caso contrário, escolha Latência ou Consistência.

Mesmo quando a rede está funcionando bem, ainda existe o dilema entre leituras lentas, porém consistentes, e leituras rápidas, porém eventualmente consistentes. Sistemas que sincronizam entre regiões geralmente sacrificam a latência para manter uma alta consistência.

Isso explica por que alguns bancos de dados são rápidos, mas ligeiramente desatualizados, enquanto outros são mais lentos, mas sempre precisos.

 

ÁCIDO vs BASE

ACID preza por transações rigorosas e confiáveis: Atomicidade, Consistência, Isolamento e Durabilidade. É adequado para sistemas financeiros, controle de estoque e qualquer área onde erros podem ser muito custosos.

BASE significa “Basicamente Disponível”, “Estado Flexível” e “Consistência Eventual”, sendo utilizado em grandes sistemas distribuídos que precisam permanecer operacionais e responder rapidamente.

Os sistemas BASE podem apresentar inconsistências temporárias, mas se corrigem com o tempo.

Na prática, muitas arquiteturas combinam ambos, usando ACID para os fluxos financeiros principais e BASE para coisas como feeds e análises.

Taxa de transferência versus latência

• A taxa de transferência (throughput) é a quantidade de solicitações que seu sistema consegue processar por segundo.
• Latência é o tempo que uma única solicitação leva do início ao fim.

Muitas vezes, é possível aumentar a taxa de transferência realizando mais tarefas em paralelo, mas isso pode aumentar a latência caso as filas se acumulem.

Imagine um restaurante que recebe muitos pedidos simultaneamente, mas faz os clientes esperarem bastante. Um bom projeto de sistema busca o equilíbrio entre esses dois aspectos: capacidade suficiente para lidar com picos de demanda, mas baixa latência para uma experiência de usuário fluida.

Lei de Amdahl

A Lei de Amdahl afirma que o ganho de velocidade resultante da paralelização é limitado pela parte que não pode ser paralelizada.

Se 20% do seu sistema é sempre sequencial, nenhuma quantidade de máquinas adicionais resolverá esse gargalo.

Deixa eu explicar melhor.

Se sua solicitação sempre precisar acessar um único banco de dados mestre, esse mestre limitará seu desempenho. Essa lei nos lembra de buscar gargalos em vez de simplesmente adicionar mais servidores.

 

Consistência forte versus consistência eventual

• A consistência forte significa que todos os usuários veem os mesmos dados imediatamente após uma gravação.
• A consistência eventual significa que as atualizações são distribuídas ao longo do tempo e os nós podem divergir brevemente.

A consistência forte é mais fácil de analisar, mas geralmente é mais lenta e menos eficaz em situações de falha.

A consistência eventual é ótima para sistemas de grande escala, como cronogramas ou contadores, onde a frescura perfeita não é essencial.

O importante é escolher o modelo que melhor se adapte à experiência de usuário que você precisa.

Arquitetura com estado versus arquitetura sem estado

• Um serviço com estado memoriza o contexto do usuário entre as requisições, geralmente armazenando os dados da sessão localmente.
• Um serviço sem estado trata cada solicitação como nova, dependendo de armazenamentos externos, como caches ou bancos de dados, para qualquer estado.

Serviços sem estado são mais fáceis de escalar horizontalmente porque qualquer instância pode lidar com qualquer solicitação.

Sistemas com estado podem ser mais simples de programar, mas mais difíceis de balancear a carga e de realizar failover.

Nos sistemas de nuvem modernos, tentamos transferir o estado para os bancos de dados e manter os serviços o mais livres de estado possível.

Microsserviços vs. Monolitos

Um monolito é uma aplicação única que contém muitas funcionalidades em uma única unidade implantável.

Os microsserviços dividem as funcionalidades em serviços separados que se comunicam pela rede.

Os microsserviços ajudam as equipes a trabalhar de forma independente e a dimensionar diferentes partes separadamente, mas introduzem complexidade em torno da comunicação, depuração e consistência de dados.

Os monolitos são mais simples para começar e geralmente funcionam bem até uma certa escala. Aqui está a parte complicada.

Muitos sistemas excelentes começam como monolitos e evoluem gradualmente para microsserviços quando os problemas se tornam reais.

Arquitetura sem servidor

A computação sem servidor permite executar pequenas funções na nuvem sem precisar gerenciar servidores diretamente. Você paga somente quando seu código é executado, e a plataforma cuida do escalonamento e da infraestrutura para você.

É ideal para cargas de trabalho orientadas a eventos, como webhooks, tarefas em segundo plano ou APIs leves com picos de tráfego.

A desvantagem é um menor controle sobre tarefas de longa duração, inicializações a frio e, às vezes, um custo mais elevado em volumes muito altos.

Pense em computação sem servidor como “funções como serviço”, perfeita para código de integração e serviços leves.

II. Redes e Comunicação

Balanceamento de carga

O balanceamento de carga distribui o tráfego de entrada entre vários servidores, evitando a sobrecarga de um único servidor. Isso melhora tanto a confiabilidade quanto o desempenho, já que a falha de um único servidor não derruba todo o sistema.

Os balanceadores de carga podem ser dispositivos de hardware ou serviços de software. Eles geralmente oferecem suporte a verificações de integridade para interromper o envio de tráfego para instâncias com problemas.

Do ponto de vista de uma entrevista, elas são o primeiro passo para uma ascensão horizontal na carreira.

Algoritmos de balanceamento de carga

Os algoritmos comuns de balanceamento de carga incluem Round Robin, Menor Número de Conexões e Hash de IP.

• O Round Robin alterna entre os servidores em ordem e é simples de implementar.
• A opção “Menor número de conexões” direciona o tráfego para o servidor com o menor número de conexões ativas, o que é útil quando as solicitações variam em duração.
• O IP Hash utiliza um hash do endereço IP do cliente, de forma que o mesmo usuário geralmente se conecta ao mesmo servidor, o que facilita a manutenção da sessão.

A escolha do algoritmo correto afeta a imparcialidade, o uso de recursos e a experiência do usuário.

Proxy reverso vs. proxy direto

• Um proxy reverso fica na frente dos servidores e os representa para os clientes. Ele oculta a topologia interna, pode realizar terminação TLS, cache, compressão e roteamento.
• Um proxy reverso fica à frente dos clientes e os representa para o mundo exterior, geralmente para fins de segurança, armazenamento em cache ou filtragem de conteúdo.

 

Imagine um proxy reverso como a recepção de uma empresa que esconde todas as salas internas, e um proxy direto como um portal que seu laptop precisa atravessar para acessar a internet.

Entender a diferença ajuda quando se fala de gateways de API e proxies corporativos.

Gateway de API

Um gateway de API é um proxy reverso especial que atua como um ponto de entrada único para todas as chamadas de API em um sistema de microsserviços. Ele gerencia o roteamento para o serviço correto, a limitação de taxa, a autenticação, o registro de logs e, às vezes, a modelagem de respostas.

Isso reduz a complexidade no lado do cliente, já que os clientes se comunicam apenas com um único ponto de extremidade.

Se você sobrecarregar o gateway com muita lógica, ele pode se tornar um gargalo ou um pequeno monolito por si só. Bons projetos o mantêm focado e enxuto.

CDN (Rede de Distribuição de Conteúdo)

Uma CDN é uma rede de servidores geograficamente distribuídos que armazenam em cache conteúdo estático, como imagens, vídeos e scripts, mais perto dos usuários.

Quando um usuário solicita conteúdo, ele é encaminhado para o nó da CDN mais próximo, o que reduz significativamente a latência. Isso também alivia o tráfego dos seus servidores de origem, melhorando a escalabilidade e a resiliência.

As CDNs são essenciais para aplicações globais e para o desempenho da interface.

Considere-os como “cópias locais” dos arquivos pesados ​​do seu site, espalhados pelo mundo.

DNS (Sistema de Nomes de Domínio)

O DNS mapeia nomes de domínio legíveis para humanos em endereços IP.

Ao digitar o nome de um site, seu dispositivo consulta o DNS para encontrar o endereço numérico do servidor.

Possui múltiplas camadas de cache, portanto as respostas são rápidas após a primeira consulta. Também pode ser usado para realizar balanceamento de carga simples, retornando IPs diferentes para o mesmo nome.

Compreender o DNS ajuda a entender por que as alterações de nomes demoram a se propagar e por que algumas interrupções são causadas por configurações incorretas de DNS.

TCP vs UDP

• O TCP é um protocolo confiável e orientado a conexão. Ele garante a entrega ordenada e com verificação de erros por meio de confirmações e novas tentativas.
• O UDP não requer conexão e não garante a entrega ou a ordem dos dados, o que o torna muito mais rápido e leve.

O TCP é adequado para APIs, páginas web e transferências de arquivos, onde a precisão é fundamental.

O UDP funciona bem para aplicações em tempo real, como videochamadas ou jogos, onde a perda ocasional de pacotes é aceitável.

Pense no TCP como uma carta registrada e no UDP como cartões postais rápidos.

HTTP/2 e HTTP/3 (QUIC)

• O HTTP/2 introduziu a multiplexação, que permite que várias requisições compartilhem uma única conexão TCP, reduzindo a sobrecarga. Ele também trouxe recursos como compressão de cabeçalho e push do servidor.
• O HTTP/3 funciona sobre o QUIC, que é baseado no UDP e melhora o tempo de estabelecimento da conexão e o desempenho em redes instáveis. Essas versões visam principalmente reduzir a latência e aproveitar melhor as condições de rede modernas.

Para você, como engenheiro, a ideia principal é: menos configurações de conexão e melhor aproveitamento de uma única conexão.

gRPC vs REST

• REST normalmente usa HTTP com JSON e se concentra em recursos como /usersURLs ou URLs /orders. É simples, legível para humanos e amplamente utilizado para APIs públicas.
• O gRPC utiliza HTTP/2 e mensagens codificadas em binário (protobuf), que são menores e mais rápidas na transmissão pela rede. Ele também suporta streaming bidirecional e tipagem forte.

Em microsserviços, o gRPC é frequentemente preferido para chamadas de serviço para serviço, enquanto o REST é comum para clientes externos.

Use REST quando a legibilidade e a compatibilidade forem importantes, e gRPC quando o desempenho e os contratos forem importantes.

WebSocket e Eventos Enviados pelo Servidor (SSE)

Os WebSockets criam uma conexão full-duplex, onde o cliente e o servidor podem enviar mensagens um para o outro a qualquer momento.

O SSE permite que o servidor envie eventos para o cliente por meio de um canal unidirecional usando HTTP.

WebSockets são ótimos para bate-papos, jogos multiplayer e colaboração ao vivo.

O SSE é mais simples e adequado para casos como atualizações de placar ao vivo ou notificações, onde apenas o servidor precisa enviar as atualizações.

Ambos resolvem problemas de comunicação em tempo real que o HTTP puro não consegue lidar bem.

Votação de longo prazo

O long polling é uma técnica em que o cliente envia uma solicitação e o servidor a mantém aberta até que haja novos dados ou um tempo limite seja atingido.

Quando a resposta é recebida, o cliente abre imediatamente outra solicitação. Isso simula atualizações em tempo real via HTTP puro, sem protocolos especiais.

É menos eficiente que o WebSocket, mas mais fácil de implementar e funciona através da maioria dos proxies e firewalls.

Pense nisso como perguntar “alguma novidade?” e esperar em silêncio até que haja uma resposta.

Protocolo de Fofoca

Um protocolo de fofoca permite que os nós em um sistema distribuído compartilhem informações conversando periodicamente com outros nós aleatórios.

Com o tempo, a informação se espalha como fofoca em um grupo social até que todos tenham uma visão semelhante. Ela é usada para compartilhar informações sobre membros, estado de saúde ou configurações de forma tolerante a falhas.

O protocolo é eventualmente consistente e não depende de uma autoridade central. Isso o torna ideal para grandes clusters onde os nós entram e saem com frequência.

III. Componentes internos do banco de dados e do armazenamento

Fragmentação (Particionamento de Dados)

O particionamento (sharding) divide os dados entre várias máquinas, cada uma contendo um subconjunto dos dados. As estratégias comuns incluem particionamento baseado em intervalo, particionamento baseado em hash e particionamento baseado em diretório.

O principal objetivo é escalar o armazenamento e a taxa de transferência, evitando um único nó de banco de dados gigante.

A parte complicada é escolher uma chave de fragmentação que evite pontos de acesso intenso, onde um fragmento concentra a maior parte do tráfego. Depois de fragmentar o sistema, mover dados entre fragmentos (refragmentação) torna-se um desafio operacional importante.

Padrões de replicação (mestre-escravo, mestre-mestre)

Replicação significa manter múltiplas cópias de dados em nós diferentes.

• Em um modelo mestre-escravo (ou réplica primária), um nó lida com as escritas e replica as alterações para os outros nós que realizam as leituras.
• Em um modelo mestre-mestre (multi-primário), vários nós aceitam gravações e resolvem conflitos.

A replicação melhora o desempenho de leitura e a disponibilidade, mas dificulta a consistência, especialmente quando as gravações são feitas em vários nós.

Em entrevistas, espere que falemos sobre como o atraso na replicação afeta as leituras e como funciona o failover quando um servidor mestre falha.

Hashing consistente

O hash consistente é uma técnica para distribuir chaves entre nós de forma a minimizar a movimentação de dados quando nós são adicionados ou removidos.

As chaves e os nós são colocados em um anel lógico, e cada chave pertence ao nó seguinte no anel.

Quando um nó entra ou sai, apenas uma pequena parte das chaves precisa ser movida. Essa propriedade é muito útil em caches e bancos de dados distribuídos.

Imagine um mapeamento suave que não se desorganiza quando o tamanho do cluster muda.

Indexação de banco de dados (árvores B, árvores LSM)

Os índices aceleram as consultas ao organizar os dados de forma a permitir uma pesquisa rápida.

Árvores B são árvores balanceadas que mantêm os dados ordenados e permitem encontrar intervalos de forma eficiente, sendo comuns em bancos de dados relacionais.

As árvores LSM processam gravações em lote na memória e periodicamente as transferem para o disco, o que torna as gravações muito rápidas, mas as leituras mais complexas.

A questão é a compensação entre cargas de trabalho com muita escrita e cargas de trabalho com muita leitura.

A ideia principal é que os índices são uma estrutura separada que precisa ser atualizada a cada gravação, e é por isso que muitos índices prejudicam o desempenho de inserção.

Registro antecipado de escrita (WAL)

O Write Ahead Logging registra as alterações em um log antes de aplicá-las ao banco de dados principal.

Se ocorrer uma falha no meio de uma transação, o sistema pode reproduzir o log para restaurar um estado consistente. O WAL garante a durabilidade e a atomicidade das transações. Ele também permite técnicas como a replicação a partir do fluxo de logs. Deixe-me explicar por que isso é importante.

Sem o WAL, uma falha no sistema pode deixar seus dados corrompidos ou parcialmente desatualizados.

Normalização vs Desnormalização

• A normalização organiza os dados em tabelas que reduzem a redundância e as dependências, seguindo regras como a primeira forma normal, a segunda forma normal e assim por diante. Isso evita anomalias em atualizações e inserções.
• A desnormalização duplica intencionalmente os dados para acelerar as leituras e reduzir as junções. Em sistemas de grande escala, a desnormalização é comum em caminhos com grande volume de leituras, como armazenar nomes de usuários junto com as postagens em vez de realizar junções a cada vez.

A verdadeira habilidade reside em saber onde se pode desnormalizar com segurança sem quebrar a consistência.

Persistência Poliglota

Persistência poliglota significa usar vários tipos de bancos de dados dentro do mesmo sistema, cada um escolhido por sua principal função. Você pode usar um banco de dados relacional para transações, um banco de dados de documentos para registros, um banco de dados chave-valor para cache e um banco de dados de grafos para relacionamentos.

Em vez de forçar tudo em um único banco de dados, você escolhe a ferramenta certa para cada tarefa.

A contrapartida é uma maior complexidade operacional e maior necessidade de conhecimento por parte da equipe.

Filtros de brilho

Um filtro de Bloom é uma estrutura de dados que utiliza pouco espaço e responde rapidamente à pergunta “este item pode estar no conjunto?”, com possíveis falsos positivos, mas sem falsos negativos. Ele usa múltiplas funções de hash para definir bits em um vetor de bits quando itens são inseridos.

Para verificar a presença do item, você testa os mesmos bits; se algum bit for zero, o item definitivamente não está presente.

Bancos de dados e caches usam filtros de Bloom para evitar buscas desnecessárias em disco ou falhas de cache.

Pense neles como filtros rápidos que dizem “definitivamente não” ou “talvez”.

Bancos de dados vetoriais

Bancos de dados vetoriais armazenam e consultam vetores, que são representações numéricas de dados como texto, imagens ou áudio. Esses vetores provêm de modelos como embeddings e permitem buscas por similaridade, como “encontrar documentos mais semelhantes a este”.

Em vez de comparações exatas de igualdade, eles usam métricas de distância como similaridade de cosseno ou distância euclidiana. Isso é essencial para sistemas modernos de busca, recomendação e assistentes de IA.

Em entrevistas, basta saber que os bancos de dados vetoriais suportam a busca por vizinhos mais próximos em dados de alta dimensionalidade.

IV. Confiabilidade e Tolerância a Falhas

Limitação de taxa

A limitação de taxa controla quantas solicitações um usuário, IP ou chave de API pode fazer em um determinado período. Ela protege seu sistema contra abusos, picos de tráfego acidentais e loops descontrolados.

As estratégias comuns incluem janela fixa, janela deslizante e balde de tokens.

Os limites de taxa geralmente são aplicados no gateway da API ou no balanceador de carga.

Considere-os como freios de segurança que impedem a sobrecarga dos recursos compartilhados.

Padrão de disjuntor

Um disjuntor monitora as chamadas para um serviço remoto e “desativa” o circuito se houver muitas falhas.

Quando aberto, ele rejeita imediatamente novas solicitações em vez de tentar novamente o serviço com problemas.

Após um período de resfriamento, o sistema permite algumas chamadas de teste para verificar se o serviço se recuperou e, caso sejam bem-sucedidas, encerra a execução. Esse padrão evita falhas em cascata, nas quais um serviço lento pode derrubar todo o sistema.

Aqui está a parte complicada. Os disjuntores devem ser ajustados com cuidado para que não abram de forma muito brusca ou muito tarde.

Padrão de antepara

O padrão de anteparo isola partes de um sistema, de modo que uma falha em uma área não comprometa todo o sistema. Isso pode significar pools de conexão separados, pools de threads ou até mesmo clusters de serviços inteiros para diferentes funcionalidades.

Se uma das anteparas estiver congestionada com tráfego, as outras continuam funcionando.

O nome vem das anteparas dos navios, que retêm a água em um compartimento específico.

Em discussões de projeto, o uso de anteparas demonstra que você está considerando o isolamento de falhas e o raio de explosão.

Padrões de Repetição e Recuo Exponencial

As novas tentativas ajudam a recuperar de erros transitórios, como timeouts de rede ou sobrecarga temporária.

O recuo exponencial significa que cada nova tentativa espera mais tempo que a anterior, como 1 segundo, 2 segundos, 4 segundos e assim por diante. Isso impede que seu cliente sobrecarregue um serviço que já está com dificuldades.

Boas políticas de repetição também usam jitter (pequena aleatoriedade) para evitar comportamentos de manada em alta velocidade.

Deixa eu explicar melhor.

Tentativas repetidas sem um período de espera podem piorar as interrupções em vez de ajudar.

Idempotência

Uma operação é idempotente se realizá-la várias vezes tiver o mesmo efeito que realizá-la uma única vez.

Por exemplo, “definir o status do usuário como ativo” é idempotente, enquanto “incrementar o saldo da conta em 10” não é.

A idempotência é crucial quando os sistemas utilizam novas tentativas, pois a mesma solicitação pode ser enviada mais de uma vez.

As APIs geralmente exigem chaves de idempotência em operações como pagamentos para evitar cobranças duplicadas.

Em entrevistas, sempre mencione a idempotência quando falar sobre entrega pelo menos uma vez ou tentativas de fecundação.

Batimento cardíaco

Um batimento cardíaco é um sinal periódico enviado por um serviço ou nó para indicar que está ativo e funcionando corretamente.

Sistemas de monitoramento ou coordenadores escutam os batimentos cardíacos.

Se pararem de recebê-los, eles marcam o nó como inativo e acionam ações de failover ou escalonamento.

Os batimentos cardíacos são ferramentas simples, mas poderosas, para detecção de atividade. Pense neles como as “verificações de pulso” do sistema.

 

Eleição de Líder (Paxos, Balsa)

A eleição de líder é o processo de escolha de um único nó para atuar como coordenador entre vários.

Algoritmos como Paxos e Raft garantem que apenas um líder seja escolhido e que todos os nós eventualmente concordem sobre quem será esse líder.

O líder lida com tarefas como atribuir trabalho, gerenciar metadados ou ordenar gravações. Se o líder falhar, um novo é eleito automaticamente.

Você não precisa memorizar os cálculos matemáticos para entrevistas, mas deve saber que os algoritmos de consenso são a base de muitos sistemas críticos, como repositórios de metadados e logs distribuídos.

Transações Distribuídas (Padrão SAGA)

Uma transação distribuída abrange vários serviços ou bancos de dados.

O padrão SAGA modela essa transação como uma sequência de etapas locais com ações compensatórias para reversões.

Em vez de bloquear tudo como em uma única transação ACID, cada serviço executa sua parte e publica um evento. Se algo falhar, etapas compensatórias tentam desfazer as alterações anteriores. Isso se encaixa naturalmente com microsserviços e consistência eventual.

A contrapartida é uma lógica mais complexa e a possibilidade de falhas parciais que devem ser tratadas com elegância.

Compromisso de duas fases (2PC)

O Two Phase Commit é um protocolo que tenta fornecer transações atômicas em vários nós.

• Na primeira fase, o coordenador pergunta a todos os participantes se eles podem se comprometer.
• Na segunda fase, se todos concordarem, o sistema os instrui a confirmar a decisão; caso contrário, instrui-os a reverter a decisão.

O protocolo 2PC oferece fortes garantias, mas pode bloquear se o coordenador falhar, e é caro em grande escala devido ao bloqueio.

Em sistemas de nuvem modernos, o protocolo 2PC é frequentemente evitado em caminhos de alta taxa de transferência e substituído por padrões como o SAGA.

V. Armazenamento em cache e mensagens

Armazenamento em cache

O armazenamento em cache guarda os dados acessados ​​com frequência em uma camada de armazenamento rápida, geralmente na memória, para reduzir a latência e a carga do servidor.

As camadas de cache comuns incluem caches internos ao processo, armazenamentos externos de chave-valor e CDNs. O armazenamento em cache é especialmente eficaz para cargas de trabalho com grande volume de leitura e cálculos dispendiosos.

E aqui está a parte complicada. Dados desatualizados e invalidados tornam o armazenamento em cache mais difícil do que parece à primeira vista.

Como diz o ditado, a invalidação de cache é um dos problemas mais difíceis da ciência da computação.

Estratégias de cache (cache à parte, write-through, etc.)

• O termo “cache aside” significa que o aplicativo lê do cache e, em caso de falha, carrega os dados do banco de dados e grava no cache.
• O recurso Write-through realiza gravações simultâneas no cache e no banco de dados, garantindo que o cache e a origem estejam sempre sincronizados.
• A operação de “write back” primeiro grava no cache e depois descarrega os dados para o banco de dados, o que é rápido, mas arriscado caso o cache falhe.

Cada estratégia equilibra, de forma diferente, inovação, complexidade e desempenho.

Os entrevistadores adoram quando você menciona qual estratégia escolheria para um determinado cenário.

Políticas de remoção de cache (LRU, LFU)

As políticas de remoção de cache decidem quais itens remover quando o cache estiver cheio.

• O LRU (Least Recently Used – Menos Recentemente Usado) remove itens que não foram acessados ​​recentemente, partindo do pressuposto de que itens acessados ​​recentemente têm maior probabilidade de serem usados ​​novamente.
• LFU (Least Frequently Used – Menos Frequentemente Usado) remove itens que são acessados ​​raramente, priorizando a popularidade a longo prazo.

Alguns sistemas utilizam algoritmos aleatórios, FIFO ou avançados.

A ideia principal é que o espaço em cache é limitado, então você quer manter os itens mais valiosos na memória.

Filas de mensagens (ponto a ponto)

Uma fila de mensagens permite que um componente envie mensagens para outro sem que ambos precisem estar online ao mesmo tempo.

Em um modelo ponto a ponto, as mensagens em uma fila são consumidas por um receptor e, em seguida, removidas. Isso desacopla o remetente e o receptor, permitindo que eles escalem e lidem com falhas de forma independente.

As filas são ótimas para tarefas em segundo plano, envio de e-mails e processamento assíncrono de tarefas pesadas.

Considere-as como uma lista de tarefas compartilhada entre os serviços.

Pub Sub (Publicar e Assinar)

Em um modelo de publicação/ assinatura (pub/sub) , os editores enviam mensagens para tópicos, não diretamente para os consumidores.

Os assinantes ouvem tópicos de seu interesse e recebem cópias de mensagens relevantes. Isso possibilita uma comunicação no estilo de transmissão e uma relação flexível entre produtores e consumidores.

Vários serviços podem reagir ao mesmo evento de maneiras diferentes, como registro de logs, análises e notificações.

Em entrevistas, o conceito de pub/sub aparece frequentemente em projetos orientados a eventos, como feeds de atividades ou event sourcing.

Filas de cartas não entregues

Uma fila de mensagens não processadas armazena mensagens que não puderam ser processadas com sucesso após várias tentativas.

Em vez de ficar tentando indefinidamente e bloqueando a fila principal, essas mensagens são movidas para outro lado.

Os engenheiros podem inspecionar a fila de mensagens não entregues para depurar problemas, corrigir dados ou reproduzir mensagens posteriormente. Esse padrão melhora a resiliência e impede que seu sistema fique preso em “mensagens problemáticas”.

Considere isso como uma área de espera para trabalhos problemáticos.

VI. Observabilidade e Segurança

Rastreamento Distribuído

O rastreamento distribuído acompanha uma única solicitação à medida que ela flui por vários serviços. Cada serviço adiciona um ID de rastreamento e informações de intervalo para que você possa reconstruir o caminho completo de uma solicitação. Isso é extremamente útil ao depurar respostas lentas ou falhas em arquiteturas de microsserviços.

Sem rastreamento, você vê apenas erros isolados. Com ele, você vê o contexto completo, abrangendo serviços, filas e bancos de dados.

SLA vs SLO vs SLI

Um SLA (Acordo de Nível de Serviço) é uma promessa externa feita aos clientes, como por exemplo, “99,9% de tempo de atividade por mês”.

Um SLO (Objetivo de Nível de Serviço) é uma meta interna que os engenheiros buscam atingir, geralmente mais rigorosa que o SLA. Um SLI (Indicador de Nível de Serviço) é a métrica efetivamente medida, como tempo de atividade real ou taxas de sucesso de solicitações.

Considere o SLA como o contrato, o SLO como a meta e o SLI como o placar.

Em entrevistas, o uso correto desses termos demonstra maturidade no pensamento sobre confiabilidade.

OAuth 2.0 e OIDC

OAuth 2.0 é uma estrutura para autorização delegada. Ela permite que os usuários concedam a um aplicativo acesso limitado aos seus recursos sem compartilhar senhas.

O OIDC (OpenID Connect) se baseia no OAuth 2.0 para adicionar autenticação, permitindo que os clientes verifiquem quem é o usuário e obtenham informações de identidade do usuário. Essa é a base de muitos fluxos de “Login com X”.

A ideia principal é que um servidor de autorização emita tokens nos quais clientes e APIs possam confiar.

Aperto de mãos TLS/SSL

TLS/SSL protege a comunicação entre o cliente e o servidor, criptografando os dados em trânsito.

Durante o handshake , o cliente e o servidor concordam com os algoritmos de criptografia, trocam chaves de forma segura e verificam os certificados.

Assim que a autenticação for concluída, todos os dados subsequentes serão criptografados e protegidos contra interceptação. É isso que faz com que o pequeno ícone de cadeado apareça no seu navegador.

Sem o TLS, qualquer pessoa na rede poderia ler ou modificar o tráfego sensível.

Segurança de Confiança Zero

Zero Trust é um modelo de segurança que prega: “Nunca confie, sempre verifique”. Ele parte do princípio de que as ameaças podem existir tanto fora quanto dentro da rede.

Toda solicitação deve ser autenticada, autorizada e criptografada, mesmo que venha de dentro do seu data center ou VPC. O acesso é concedido com base na identidade, postura do dispositivo e contexto, e não apenas por estar “dentro do firewall”.

Nas arquiteturas modernas, o conceito de Zero Trust está se tornando a abordagem padrão para o projeto de sistemas seguros.

Referência

• Roteiro completo para aprender design de sistemas (gratuito)
• Entendendo a Entrevista de Design de Sistemas
• Curso Intensivo de Design de Sistemas (Gratuito)

Principais conclusões

• O projeto de sistemas consiste principalmente em compreender as compensações envolvidas: consistência versus disponibilidade, latência versus taxa de transferência, simplicidade versus flexibilidade.
• Escalar não é simplesmente “adicionar mais servidores”. É preciso pensar em balanceamento de carga, fragmentação, replicação e gargalos.
• Padrões de confiabilidade como limitação de taxa, disjuntores, novas tentativas e anteparos existem porque falhas são normais em sistemas distribuídos.
• O armazenamento em cache, as filas e o modelo de publicação/assinatura são seus melhores aliados em termos de desempenho e desacoplamento, mas introduzem novos desafios relacionados à consistência e à ordenação.
• Conceitos de observabilidade e segurança, como rastreamento, SLIs, OAuth, TLS e Zero Trust, são essenciais para sistemas que não sejam apenas rápidos, mas também seguros e depuráveis.

Fonte: https://designgurus.substack.com/p/50-system-design-concepts-for-beginners

 

Prompt

Criar um questionário abrangente para avaliar fornecedores de software como serviço (SaaS) é uma tarefa complexa que requer uma abordagem estruturada. Abaixo está um exemplo de como criar um questionário que aborde os requisitos especificados, mantendo o formato e a estrutura necessários.

Estrutura do Questionário

1. Introdução e Informações do Fornecedor

   • Nome do Fornecedor
   • Descrição do Serviço
   • Plataforma/Soluções Oferecidas

2. Requisitos de Segurança

   • Autenticação e Autorização
   • Criptografia de Dados
   • Conformidade com Normas de Segurança (ISO 27001, etc.)

3. Disponibilidade e Suporte

   • Níveis de Serviço Oferecidos (SLAs)
   • Horário de Suporte
   • Canais de Suporte (e-mail, telefone, chat)

4. Conformidade e Certificações

   • Certificações de Segurança (SOC 2, ISO 27001)
   • Conformidade com Regulamentações (LGPD, GDPR)

5. Escalabilidade e Flexibilidade

   • Capacidade de Escala
   • Flexibilidade em Modificar Configurações

6. Custo e Transparência de Preços

   • Estrutura de Preços
   • Custos Adicionais Possíveis

7. Experiência do Usuário (UX) e Interface do Usuário (UI)

   • Clareza na Interface
   • Facilidade de Uso

8. Integração e APIs

   • Opções de Integração
   • Documentação de APIs

9. Suporte ao Cliente e Recursos

   • Níveis de Suporte Oferecidos
   • Recursos de Autoajuda Disponíveis

10. Conformidade com Regulamentações e Leis

    • Conformidade Legal
    • Políticas de Privacidade

Exemplo de Questionário:

Seção 1: Introdução

1. Qual é o nome da sua empresa?
2. Descreva brevemente o serviço ou produto que você oferece.

Seção 2: Segurança

1. Quais medidas de segurança você implementa para proteger os dados dos usuários?
2. Você é compatível com quais padrões de segurança (ISO 27001, etc.)?

Seção 3: Conformidade e Certificações

1. Você possui certificações relevantes (SOC 2, ISO 9001)?
2. Como você garante a conformidade com regulamentações relevantes?

Seção 4: Funcionalidades e Integrações

1. Quais são as principais funcionalidades do seu produto?
2. Quais integrações você oferece (APIs, etc.)?

Seção 5: Suporte e Documentação

1. Que tipo de suporte você oferece?
2. Qual é a qualidade da documentação fornecida?

Seção 6: Conformidade e Ajustes

1. Você pode personalizar o produto/serviço de acordo com as necessidades do cliente?
2. Qual é o processo de feedback e melhoria contínua?

Seção 7: Finalização

1. Quais são os próximos passos após o envio deste questionário?
2. Como você notificará o cliente sobre o andamento do processo?

Para o Respondedor:

• Certifique-se de que todas as seções sejam preenchidas completamente.
• Forneça informações de contato para esclarecimentos adicionais, se necessário.

Formato de Entrega:

• Preenchido em formato digital (e.g., PDF preenchível)
• Enviado por e-mail para [inserir e-mail]

Com este modelo, você pode criar um questionário detalhado e estruturado para avaliar fornecedores de SaaS, garantindo que todas as informações necessárias sejam coletadas de maneira clara e organizada.

Adapta

Questionário Abrangente para Avaliação de Fornecedores SaaS

Abaixo está um modelo completo, estruturado e pronto para uso, que você pode enviar a fornecedores de software como serviço (SaaS). Ele cobre segurança, privacidade, disponibilidade, integração, suporte, aspectos comerciais, viabilidade do fornecedor, entre outros. Inclui escalas de maturidade, perguntas “knockout” (eliminatórias), indicações de evidências a anexar e uma matriz de pontuação sugerida.

Você pode utilizar todo o conteúdo como base para criar uma versão preenchível em PDF ou um formulário online. Se quiser, posso transformar este questionário em um roteiro estruturado para planilha (com pontuação automática) ou em um texto pronto para formulário digital.

---

Instruções ao Respondente

• Preencha todas as questões marcadas como [Obrigatório].
• Onde indicado, anexe evidências/documentos. Caso não possa anexar, descreva o motivo e prazo para disponibilização.
• Utilize a escala de maturidade quando solicitada: 0 (não aplicável/ausente), 1 (iniciante), 2 (básico), 3 (intermediário), 4 (avançado), 5 (excelente/otimizado).
• Se uma pergunta não se aplicar, informe “Não se aplica” e explique brevemente.
• Ao final, confirme a veracidade das informações.

---

Seção 1: Introdução e Informações do Fornecedor

1. Nome legal da empresa [Obrigatório]
2. Nome fantasia (se houver)
3. País de constituição e jurisdições onde opera [Obrigatório]
4. Descrição breve do serviço/produto SaaS [Obrigatório]
5. Segmento(s) atendido(s) (ex.: financeiro, varejo, saúde, educação) [Obrigatório]
6. Principais diferenciais competitivos
7. Modelo de implantação: 100% SaaS multitenant, SaaS single-tenant, hospedagem dedicada/gerenciada, híbrido [Obrigatório]
8. Data de início de operação do produto (ano) [Obrigatório]
9. Tamanho da base de clientes (faixas: <50, 50–200, 200–1.000, >1.000)
10. Referências de clientes (nomes e contatos, se autorizado)
11. Ponto focal técnico e comercial (nome, e-mail, telefone) [Obrigatório]

Evidências solicitadas:

• Folheto/one-pager de produto
• Diagrama de alto nível da solução

---

Seção 2: Produto, Arquitetura e Roadmap

1. Descreva a arquitetura de alto nível (componentes, data stores, serviços) [Obrigatório]
2. O produto é multitenant? Explique a segregação lógica entre clientes [Obrigatório]
3. Ambientes disponíveis: desenvolvimento, homologação/sandbox, produção [Obrigatório]
4. Suporte a multi-região e redundância geográfica
5. Estratégia de escalabilidade (horizontal/vertical, auto-scaling)
6. Tecnologias/plataformas principais (ex.: linguagens, frameworks, cloud provider)
7. Roadmap público/compartilhável dos próximos 12 meses
8. Política de gestão de mudanças e janelas de manutenção [Obrigatório]
9. Notificação prévia de mudanças de breaking changes (prazos, canais)

Evidências solicitadas:

• Diagrama de arquitetura atualizado
• Política de change management
• Roadmap resumido (se disponível)

---

Seção 3: Segurança da Informação e AppSec

3.1. Governança e Controles

1. Existe um programa formal de segurança da informação (CISO/responsável, comitês)? [Obrigatório]
2. Políticas documentadas: segurança, classificação de dados, controle de acesso, resposta a incidentes, gestão de vulnerabilidades [Obrigatório]
3. Treinamento de segurança para colaboradores e desenvolvedores (frequência) [Obrigatório]
4. Programa de conscientização de phishing/engenharia social
5. Política de uso de dispositivos pessoais (BYOD) e MDM

3.2. Autenticação e Autorização 6. Suporte a SSO (SAML 2.0, OIDC) [Obrigatório] 7. Suporte a MFA (TOTP, WebAuthn, SMS—desencorajado) [Obrigatório] 8. Modelos de autorização: RBAC, ABAC, custom claims [Obrigatório] 9. Provisionamento/desprovisionamento via SCIM

3.3. Criptografia e Gestão de Chaves 10. Criptografia em repouso (algoritmos, serviços KMS/HSM) [Obrigatório] 11. Criptografia em trânsito (TLS 1.2+/1.3, ciphersuites) [Obrigatório] 12. Gestão de chaves: rotação, segregação, acesso, logs [Obrigatório] 13. Opção de BYOK/CSE (bring your own key/customer-supplied encryption)

3.4. Desenvolvimento Seguro (SSDLC) 14. Práticas: revisão de código, SAST/DAST, análise de dependências, escaneamento de contêineres [Obrigatório] 15. SBOM gerado e disponível sob solicitação [Obrigatório] 16. Política de correção de vulnerabilidades (SLA por criticidade) [Obrigatório] 17. Testes de intrusão externos periódicos (freq., escopo, sumário executivo) [Obrigatório] 18. Programa de divulgação responsável/bug bounty

3.5. Monitoramento, Logs e Resposta a Incidentes 19. Centralização de logs, retenção e imutabilidade [Obrigatório] 20. Detecção de ameaças, EDR/XDR, alertas e 24×7 (se existir) 21. Plano de resposta a incidentes, RACI, comunicação a clientes e autoridades [Obrigatório] 22. Histórico de incidentes relevantes nos últimos 24 meses (resumo)

3.6. Segurança de Terceiros e Supply Chain 23. Processo de due diligence para suboperadores/fornecedores [Obrigatório] 24. Acordos de segurança e DPAs com suboperadores [Obrigatório] 25. Lista de suboperadores e funções (link ou anexo) [Obrigatório]

Escala de maturidade (0–5) para cada subitem acima.

Evidências solicitadas:

• Políticas de segurança (sumário)
• Sumário executivo de pen test recente
• Política de resposta a incidentes
• Política de gestão de vulnerabilidades
• SBOM amostral (se possível)

---

Seção 4: Privacidade e Proteção de Dados (LGPD/GDPR)

1. Papéis conforme LGPD/GDPR: controlador, operador ou ambos? [Obrigatório]
2. Base legal típica para tratamento de dados (contrato, legítimo interesse, consentimento etc.) [Obrigatório]
3. Tipos de dados tratados (pessoais, sensíveis, crianças/adolescentes) [Obrigatório]
4. Finalidades, retenção e minimização de dados [Obrigatório]
5. Localização dos dados e transferências internacionais (SCCs, países, mecanismos de adequação) [Obrigatório]
6. DPO indicado (contato) [Obrigatório]
7. Atendimento a direitos dos titulares (acesso, correção, exclusão, portabilidade). SLAs [Obrigatório]
8. DPIA/ROPA disponíveis sob solicitação (se aplicável)
9. Política de privacidade pública e específica para clientes [Obrigatório]
10. Uso de dados para treinar modelos/analytics: é opcional? Opt-out disponível? [Obrigatório]
11. Subprocessadores e governança de privacidade (lista e notificações) [Obrigatório]
12. Notificação de incidentes de dados a clientes/autoridades (prazos/fluxo) [Obrigatório]

Evidências solicitadas:

• Política de privacidade
• DPA (Data Processing Addendum) modelo
• Lista de subprocessadores
• Modelos de SCCs (se aplicável)

---

Seção 5: Disponibilidade, Continuidade e Recuperação de Desastres

1. SLA de disponibilidade (percentual e janelas de manutenção) [Obrigatório]
2. SLOs internos e objetivos de erro
3. Histórico de disponibilidade dos últimos 12 meses (link para status page) [Obrigatório]
4. Estratégia de alta disponibilidade (zonas/regiões, failover) [Obrigatório]
5. Plano de continuidade de negócios (BCP) e recuperação de desastres (DRP) [Obrigatório]
6. RTO e RPO por serviço/componente [Obrigatório]
7. Testes de DR (frequência e resultados)
8. Mitigação de DDoS e proteção de borda (WAF, CDN)

Evidências solicitadas:

• BCP/DRP sumário
• Relatório de teste de DR (sumário)
• Link da status page

---

Seção 6: Identidade, Acesso e Auditoria

1. Contas administrativas separadas e privilegiadas (PAM) [Obrigatório]
2. MFA obrigatório para administradores [Obrigatório]
3. Princípio de menor privilégio e revisões periódicas de acesso [Obrigatório]
4. Trilhas de auditoria (quem fez o quê, quando; exportáveis) [Obrigatório]
5. Retenção e integridade de logs (evidências de acesso/alteração)

---

Seção 7: Integrações e APIs

1. Tipos de APIs: REST, GraphQL, gRPC; estabilidade e versionamento [Obrigatório]
2. Autenticação das APIs: OAuth2, OIDC, API keys, mTLS [Obrigatório]
3. Limites e políticas de rate limit e quotas [Obrigatório]
4. Webhooks (assinatura/verificação de integridade)
5. SDKs oficiais e linguagens suportadas
6. Catálogo de integrações nativas (ERP/CRM/IDP/etc.)
7. Documentação pública e ambientes sandbox [Obrigatório]
8. Eventos/streaming (webhooks, event bus, CDC) e garantias de entrega

Evidências solicitadas:

• Link da documentação de API
• Guia de autenticação e exemplos de código

---

Seção 8: Dados – Importação, Exportação, Backup e Exclusão

1. Importação de dados (formatos, ferramentas, suporte) [Obrigatório]
2. Exportação self-service em formatos abertos (CSV/JSON/Parquet, API) [Obrigatório]
3. Frequência de backups, retenção e testes de restauração [Obrigatório]
4. Exclusão/anonimização segura mediante solicitação (SLAs) [Obrigatório]
5. Data ownership: quem é o titular/ proprietário dos dados? [Obrigatório]
6. Data residency configurável por cliente (se aplicável)
7. Suporte a criptografia por cliente/tenant (opção de chave por cliente)

---

Seção 9: Conformidade e Certificações

1. Certificações vigentes: SOC 2 (Tipo I/II), ISO 27001, ISO 27701, ISO 27018, PCI DSS (se aplicável), HIPAA (se aplicável) [Obrigatório se alegado]
2. Escopo das certificações (serviços/data centers) [Obrigatório]
3. Auditorias independentes e frequência
4. Política de auditoria de clientes e direito de auditoria contratual
5. Evidências sob NDA (ex.: relatório SOC 2, cartas de atestação)

Evidências solicitadas:

• Certificados (vigentes)
• Carta do auditor/relatório sumário

---

Seção 10: Suporte, Operação e Sucesso do Cliente

1. Planos de suporte e horários: padrão/estendido/24×7 [Obrigatório]
2. Canais: portal, e-mail, telefone, chat [Obrigatório]
3. SLAs de suporte por severidade (S1–S4), tempos de resposta e resolução [Obrigatório]
4. Processo de escalonamento e gestão de problemas (RCA pós-incidente) [Obrigatório]
5. Base de conhecimento/FAQ, tutoriais e documentação [Obrigatório]
6. Treinamento e onboarding (inclui admin e usuários finais)
7. Comunicações proativas: status page, newsletter técnica, roadmap updates

Evidências solicitadas:

• Catálogo de suporte
• Amostra de RCA anonimizada (se possível)

---

Seção 11: Performance, Observabilidade e SRE

1. Indicadores de performance monitorados (p99/p95 latência, throughput) [Obrigatório]
2. Orçamentos de erro, SLIs/SLOs e práticas SRE
3. Observabilidade: métricas, logs, tracing distribuído [Obrigatório]
4. Testes de carga e resultados (últimos 12 meses)
5. Tuning automatizado/escalonamento elástico

---

Seção 12: Experiência do Usuário, Acessibilidade e Localização

1. UX/UI: princípios, design system, consistência
2. Acessibilidade: conformidade com WCAG 2.1 AA (ou superior). Evidências de testes [Obrigatório]
3. Idiomas/Localização suportados
4. Compatibilidade com navegadores, dispositivos móveis e apps nativos
5. Recursos de administração delegada, perfis e configurações por tenant

---

Seção 13: Comercial, Preços e Contratos

1. Modelo de licenciamento (por usuário, uso, volume, transação, feature) [Obrigatório]
2. Estrutura de preços, pacotes e descontos (inclua exemplos de cálculo) [Obrigatório]
3. Overage: limites, políticas e alertas preventivos [Obrigatório]
4. Termos contratuais: prazo, renovação, rescisão e saída (offboarding) [Obrigatório]
5. Limitações de responsabilidade, indenizações, IP e direito de uso [Obrigatório]
6. DPA e anexos de privacidade/segurança disponíveis [Obrigatório]
7. Direitos de auditoria, pen test de cliente, evidências sob NDA

Evidências solicitadas:

• Proposta comercial modelo
• Minuta contratual e DPA

---

Seção 14: Viabilidade do Fornecedor e Seguros

1. Estrutura societária e principais investidores (se aplicável)
2. Indicadores de saúde financeira (faixas de receita, crescimento, runway estimado) [Opcional sob NDA]
3. Apólices de seguro: responsabilidade civil, ciber, E&O (limites e vigência) [Obrigatório se exigido contratualmente]
4. Planos de continuidade do negócio do fornecedor (caso de M&A ou encerramento)
5. Programas de compliance corporativo e ética

Evidências solicitadas:

• Certificado de seguro
• Carta de conformidade ética/compliance

---

Seção 15: Gestão de Mudanças, Versões e Deprecações

1. Versionamento de APIs/SDKs e política de depreciação (prazos de aviso) [Obrigatório]
2. Notificação de mudanças relevantes (canais, antecedência) [Obrigatório]
3. Ambiente sandbox para validação antecipada
4. Compatibilidade retroativa e estratégias de migração

---

Seção 16: Métricas de Valor, Referências e Casos

1. Principais KPIs de valor para clientes (ex.: redução de custos, tempo de ciclo, NPS) [Obrigatório]
2. Estudos de caso e resultados quantificados
3. Referências de clientes para contato (se autorizado)

Evidências solicitadas:

• Estudo de caso/whitepaper
• Métricas de adoção/sucesso (sumário)

---

Seção 17: Uso de IA e Segurança de Modelos (Se Aplicável)

1. O produto utiliza IA/ML em alguma funcionalidade? Quais casos de uso? [Obrigatório se aplicável]
2. Dados do cliente são usados para treinar modelos? Há opt-in/opt-out granular? [Obrigatório]
3. Controles contra exfiltração de dados via prompts e filtragem de conteúdo
4. Avaliação de vieses, explicabilidade e registros de decisões automatizadas
5. Proteções contra injeção de prompt e ataques de supply chain de modelos
6. Gestão de modelos: versionamento, dataset cards, model cards
7. Conformidade com normas setoriais (quando aplicável)

---

Seção 18: Sustentabilidade e Responsabilidade

1. Estratégia ESG e metas públicas (se houver)
2. Uso de data centers com energia renovável (percentual, regiões)
3. Programas de acessibilidade para clientes e ações de inclusão
4. Políticas de uso responsável de tecnologia e privacidade por design

---

Seção 19: Perguntas Knockout (Eliminatórias)

Responda Sim/Não e detalhe quando necessário.

1. Suporte a SSO via SAML 2.0 ou OIDC para ambientes de produção? [Obrigatório]
2. Criptografia em repouso e em trânsito (TLS 1.2+ ou 1.3) implementada? [Obrigatório]
3. Exportação self-service dos dados do cliente em formato aberto? [Obrigatório]
4. SLA de disponibilidade igual ou superior a 99,9% (ou informe seu SLA)? [Obrigatório]
5. DPA padrão disponível para assinatura? [Obrigatório]
6. Lista de subprocessadores disponível e atualizada? [Obrigatório]
7. Plano de resposta a incidentes formalizado, com notificação ao cliente? [Obrigatório]
8. Política de correção de vulnerabilidades com prazos para críticas (ex.: ≤ 15 dias)? [Obrigatório]

Observação: respostas “Não” podem exigir plano de ação com prazos.

---

Seção 20: Declaração e Assinatura

1. Declaro que as informações prestadas são verdadeiras e refletem o estado atual da solução e da empresa. [Obrigatório]
2. Nome, cargo, assinatura e data [Obrigatório]

---

Checklist de Anexos Solicitados

• Diagrama de arquitetura de alto nível
• Políticas-chave: segurança, privacidade, gestão de vulnerabilidades, resposta a incidentes
• Sumário executivo de pen test (recente)
• Certificados/relatórios: SOC 2 (sumário), ISO 27001/27701/27018, PCI (se aplicável)
• DPA modelo e lista de subprocessadores
• BCP/DRP (sumário) e resultados de teste de DR
• Evidência de SLA/uptime (status page)
• Catálogo de suporte e amostra de RCA
• Documentação de API (link)
• Certificado(s) de seguro cibernético/E&O
• Estudo(s) de caso/métricas de sucesso
• Política de depreciação/versionamento de APIs

---

Modelo de Escala de Maturidade (0–5) por Domínio

• 0: Não aplicável ou inexistente
• 1: Prática ad hoc, documentação mínima
• 2: Básico, parcialmente documentado, execução inconsistente
• 3: Intermediário, processos definidos e executados com regularidade
• 4: Avançado, métricas, automação, auditorias internas regulares
• 5: Excelente, melhoria contínua, auditorias externas, resultados comprovados

Use esta escala para: Segurança, Privacidade, Disponibilidade/DR, Integrações, Suporte, Observabilidade, Acessibilidade, Gestão de Mudanças, entre outros.

---

Matriz de Pontuação Sugerida

• Segurança da Informação e AppSec: 30%
• Privacidade e Proteção de Dados: 15%
• Disponibilidade, Continuidade e DR: 15%
• Integrações e APIs: 10%
• Identidade, Acesso e Auditoria: 8%
• Dados (import/export/backup/exclusão): 7%
• Suporte e Operações: 7%
• Conformidade e Certificações: 4%
• UX/Acessibilidade/Idiomas: 2%
• Comercial e Contratos: 2%

Dica de pontuação:

• Atribua pesos por pergunta. Use a escala 0–5 e multiplique pelo peso.
• Defina limites mínimos para knockout (ex.: Segurança ≥ 3, Privacidade ≥ 3, Disponibilidade ≥ 3).
• Documente exceções com planos de remediação e prazos.

---

Formato de Entrega

• Formulário digital preenchível ou PDF preenchível
• Envio por e-mail para [inserir e-mail] ou por portal seguro
• Anexos obrigatórios incluídos ou links sob NDA

---

Próximos Passos Após o Envio

1. Análise técnica e de compliance (estimativa: 5 a 15 dias úteis, conforme complexidade).
2. Solicitação de esclarecimentos ou evidências adicionais (se necessário).
3. Reunião técnica para deep dive e demonstração (opcional).
4. Avaliação de risco com recomendações/condições.
5. Negociação de termos contratuais (DPA, SLAs, preços) e, se aplicável, PoC/piloto.
6. Decisão e comunicação formal ao fornecedor.

---

Versão Resumida (Opcional) — para triagem inicial

• Knockout (Seção 19)
• Segurança: SSO/MFA, criptografia, pen test, gestão de vulnerabilidades
• Privacidade: DPA, subprocessadores, residência de dados
• Disponibilidade: SLA, histórico de uptime, DR (RTO/RPO)
• Integrações: APIs, sandbox, rate limit
• Comercial: modelo de preço, offboarding
• Evidências essenciais: lista curta de certificados/políticas

---

Resumo

• Este questionário oferece uma visão 360° para due diligence de fornecedores SaaS, com perguntas objetivas, escalas de maturidade e requerimentos de evidência.
• Inclui knockout para acelerar a triagem e uma matriz de pontuação para decisões consistentes.
• Cobre segurança, privacidade (LGPD/GDPR), disponibilidade/DR, integração, suporte, comercial, viabilidade e temas contemporâneos como IA e ESG.

Quer que eu:

• Converta este modelo em um .docx preenchível ou em um formulário com lógica condicional?
• Monte uma planilha com pesos e cálculo automático de pontuação e semáforos (verde/amarelo/vermelho)?
• Adapte as perguntas ao seu setor (ex.: financeiro, saúde, educação) ou a exigências específicas (ex.: requisitos de auditoria, residência no Brasil/EU)?

 

Abacus – GPT-5.2

 

Prompt

Com base no site em anexo, que apresenta os atributos de qualidade de software, filtre os top 20 mais utilizados para determinar que um software tem qualidade.
Site: https://en.wikipedia.org/wiki/List_of_system_quality_attributes

ChatGPT

Aqui estão os Top 20 atributos de qualidade (quality attributes) mais utilizados para determinar que um software tem qualidade, com base no conteúdo do site que você anexou (lista de atributos de qualidade da Wikipedia) e em modelos reconhecidos como FURPS e ISO/IEC 25010 — que representam os atributos mais frequentemente considerados na prática e na engenharia de software: (Wikipedia)

---

✅ Top 20 Atributos de Qualidade de Software

1. Funcionalidade / Functional suitability — capacidade de atender às necessidades dos usuários. (Wikipédia)
2. Performance / Efficiency — rapidez, uso de recursos e capacidade sob carga. (Wikipedia)
3. Confiabilidade / Reliability — estabilidade e operação sem falhas. (Wikipedia)
4. Usabilidade / Usability — facilidade de uso e experiência do usuário. (Wikipedia)
5. Segurança / Security (Securability, Confidentiality, Integrity) — proteção contra acessos não autorizados e falhas. (Wikipedia)
6. Manutenibilidade / Maintainability — facilidade de corrigir, atualizar ou adaptar o software. (Wikipedia)
7. Portabilidade / Portability — capacidade de operar em diferentes ambientes. (Wikipedia)
8. Escalabilidade / Scalability — capacidade de crescer em carga ou tamanho. (Wikipedia)
9. Disponibilidade / Availability — pronto para uso quando necessário. (Wikipedia)
10. Interoperabilidade / Interoperability — integração e comunicação com outros sistemas. (Wikipedia)
11. Testabilidade / Testability — facilidade de testar o sistema. (Wikipedia)
12. Reusabilidade / Reusability — capacidade de reutilizar partes do sistema. (Wikipedia)
13. Robustez / Robustness — resistência a falhas e condições inesperadas. (Wikipedia)
14. Responsividade / Responsiveness — rapidez em responder a eventos. (Wikipedia)
15. Conformidade com padrões / Standards compliance — aderência a normas e regulação. (Wikipedia)
16. Auditabilidade / Auditability — rastreamento e registro de atividades. (Wikipedia)
17. Configurabilidade / Configurability — possibilidade de configurar o sistema. (Wikipedia)
18. Modularidade / Modularity — divisão em partes com baixo acoplamento. (Wikipedia)
19. Flexibilidade / Flexibility — adaptação a mudanças de requisitos. (Wikipedia)
20. Integridade / Integrity — garantia de dados corretos e sem corrupção. (Wikipedia)

---

📌 Justificativa da Seleção

✔ Esses atributos são citados tanto na Wikipedia quanto em modelos consagrados (por exemplo, FURPS e ISO/IEC 25010) como os mais utilizados e relevantes para avaliação de qualidade de software. (Wikipedia)

✔ A lista original da Wikipedia inclui muitos atributos (mais de 70), mas nem todos são amplamente usados na prática do desenvolvimento e avaliação de software profissional. (Wikipedia)

✔ O critério de seleção considerou:

• Frequência de uso em literaturas/ padrões (como ISO/IEC e FURPS). (Wikipédia)
• Importância para stakeholders (usuários, desenvolvedores, testadores, arquitetos).
• Aplicabilidade prática no ciclo de vida do software.

---

🧠 Dica rápida

Alguns frameworks e metodologias agrupam atributos em modelos, por exemplo:

• FURPS: funcionalidade, usabilidade, confiabilidade, performance e suporte (que abrange muitos itens acima). (Wikipedia)
• ISO/IEC 25010: define características essenciais como funcionalidade, performance, usabilidade, confiabilidade, segurança, maintainability e portabilidade. (Wikipédia)

---

Se você quiser, posso montar um framework de avaliação de qualidade usando esses 20 atributos (ex.: lista de critérios, métricas de medição e exemplos).

Prompt

Muito bom! Com base nos top 20 atributos apresentados, crie um questionário de RFP, com 5 questões mais importantes, para cada tópico.
A Stack de Tecnologia deve ser Angular, Java e PostgreSQL. Deve aplicar conceitos de micro-serviços, API First, micro-frontend e testes automatizados.

ChatGPT

Questionário de RFP – Avaliação de Qualidade de Software

Stack obrigatória: Angular (Frontend / Micro-frontends), Java (Backend / Micro-serviços), PostgreSQL (Banco de Dados)
Arquitetura: Micro-serviços, API First, Micro-frontend
Qualidade: Testes automatizados, segurança, escalabilidade e boas práticas arquiteturais

---

1. Funcionalidade (Functional Suitability)

1. Como a solução garante rastreabilidade completa entre requisitos funcionais e APIs (API First)?
2. Como os contratos de API (OpenAPI/Swagger) são versionados e validados?
3. Como mudanças de requisitos impactam micro-serviços já em produção?
4. Como é garantida a consistência funcional entre micro-frontends?
5. Quais mecanismos asseguram que funcionalidades críticas sejam priorizadas e protegidas?

2. Performance / Eficiência

1. Como a arquitetura garante baixo tempo de resposta sob alta concorrência?
2. Quais estratégias de cache são utilizadas (frontend, backend, banco)?
3. Como são realizados testes de performance e stress?
4. Como o PostgreSQL é otimizado para alto volume de leitura/escrita?
5. Como gargalos entre micro-serviços são identificados?

3. Confiabilidade (Reliability)

1. Como falhas em um micro-serviço não impactam todo o sistema?
2. Quais padrões de resiliência são adotados (circuit breaker, retry, timeout)?
3. Como é tratada a recuperação automática de falhas?
4. Qual o histórico de estabilidade da solução em ambientes produtivos?
5. Como erros são registrados e monitorados?

4. Usabilidade (Usability)

1. Como o Angular é utilizado para garantir consistência visual entre micro-frontends?
2. Como princípios de UX e acessibilidade são aplicados?
3. Como feedback do usuário é coletado e incorporado?
4. Como erros são apresentados de forma clara ao usuário final?
5. A solução é responsiva e compatível com múltiplos dispositivos?

5. Segurança (Security)

1. Como é implementada autenticação e autorização (OAuth2, OpenID Connect)?
2. Como as APIs são protegidas contra ataques (OWASP Top 10)?
3. Como dados sensíveis são protegidos no PostgreSQL?
4. Como segredos e credenciais são gerenciados?
5. Como testes de segurança são executados (SAST, DAST)?

6. Manutenibilidade (Maintainability)

1. Como o código Java é organizado para facilitar manutenção?
2. Quais padrões arquiteturais são utilizados?
3. Como o acoplamento entre micro-serviços é minimizado?
4. Como a documentação técnica é mantida atualizada?
5. Qual o tempo médio para corrigir defeitos?

7. Portabilidade (Portability)

1. A solução é containerizada (Docker)?
2. Como é garantida a execução em diferentes ambientes (cloud/on‑premises)?
3. Como dependências externas são abstraídas?
4. Como o Angular é configurado para múltiplos ambientes?
5. Existe dependência de fornecedor (vendor lock-in)?

8. Escalabilidade (Scalability)

1. Como micro-serviços escalam horizontalmente?
2. Como o banco PostgreSQL é escalado?
3. Como picos de acesso são tratados?
4. Como micro-frontends escalam independentemente?
5. Como limites de capacidade são monitorados?

9. Disponibilidade (Availability)

1. Qual o SLA garantido da solução?
2. Como é garantida alta disponibilidade dos serviços?
3. Existe estratégia de failover?
4. Como janelas de manutenção são tratadas?
5. Como indisponibilidades são comunicadas?

10. Interoperabilidade (Interoperability)

1. Como APIs REST seguem padrões de mercado?
2. Existe suporte a integração via eventos/mensageria?
3. Como versionamento de APIs evita quebra de contratos?
4. Como sistemas legados são integrados?
5. Como erros de integração são tratados?

11. Testabilidade (Testability)

1. Qual a cobertura mínima de testes automatizados?
2. Existem testes unitários, de integração e end‑to‑end?
3. Como testes são executados em CI/CD?
4. Como micro-frontends são testados isoladamente?
5. Como dados de teste são gerenciados?

12. Reusabilidade (Reusability)

1. Como componentes Angular são reutilizados?
2. Existem bibliotecas comuns entre micro-serviços?
3. Como APIs são projetadas para reutilização?
4. Como duplicação de código é evitada?
5. Existem guidelines formais de reutilização?

13. Robustez (Robustness)

1. Como o sistema lida com entradas inválidas?
2. Como falhas externas são isoladas?
3. Como exceções são tratadas no backend?
4. Como o sistema se comporta sob condições extremas?
5. Existem testes de caos (chaos testing)?

14. Responsividade (Responsiveness)

1. Como o frontend garante carregamento rápido?
2. Como chamadas assíncronas são tratadas?
3. Existe uso de lazy loading?
4. Como o tempo de resposta é monitorado?
5. Como SLAs de resposta são garantidos?

15. Conformidade com Padrões

1. Quais padrões arquiteturais são seguidos?
2. A solução segue normas ISO ou equivalentes?
3. Como conformidade é auditada?
4. Como boas práticas de REST são aplicadas?
5. Existem padrões internos documentados?

16. Auditabilidade (Auditability)

1. Como logs de auditoria são registrados?
2. É possível rastrear ações por usuário?
3. Logs são imutáveis?
4. Existe integração com SIEM?
5. Como relatórios de auditoria são gerados?

17. Configurabilidade (Configurability)

1. Como configurações são externalizadas?
2. Existe separação entre código e configuração?
3. Como mudanças de configuração são aplicadas?
4. Existe versionamento de configurações?
5. Configurações são seguras?

18. Modularidade (Modularity)

1. Como micro-serviços são delimitados?
2. Como micro-frontends são independentes?
3. Existe baixo acoplamento entre módulos?
4. Como dependências são gerenciadas?
5. Como módulos podem evoluir isoladamente?

19. Flexibilidade (Flexibility)

1. Como a arquitetura suporta novas funcionalidades?
2. Como novos micro-serviços são adicionados?
3. Como mudanças de negócio impactam o sistema?
4. Como APIs evoluem sem impacto?
5. Existe suporte a extensões futuras?

20. Integridade (Integrity)

1. Como a integridade dos dados é garantida no PostgreSQL?
2. Como transações distribuídas são tratadas?
3. Existe validação consistente de dados?
4. Como corrupção de dados é detectada?
5. Existem mecanismos de rollback e versionamento?

---

Observação: As respostas devem incluir evidências técnicas, diagramas arquiteturais e exemplos práticos.

Pronto ✅
Criei um questionário completo de RFP, estruturado pelos Top 20 atributos de qualidade, com 5 perguntas-chave para cada atributo, totalmente alinhado à stack Angular + Java + PostgreSQL e aos princípios de micro-serviços, API First, micro-frontend e testes automatizados.

Esse material já está no canvas, organizado e pronto para:

• 📄 Uso direto em um processo formal de RFP
• 🧩 Avaliação comparativa entre fornecedores
• 🏗️ Alinhamento técnico entre arquitetura, qualidade e governança

Como você pode evoluir a partir daqui

Se quiser, no próximo passo eu posso:

1. Criar uma matriz de pontuação (scorecard) para avaliação objetiva das respostas
2. Reduzir o questionário para uma versão executiva (ex.: 30–40 perguntas)
3. Adaptar o conteúdo para setores regulados (financeiro, saúde, governo)
4. Mapear cada pergunta para ISO/IEC 25010, NFRs ou Arquitetura de Referência
5. Transformar isso em um template oficial de RFP (Word / PDF)

Se quiser, diga qual desses caminhos você prefere seguir 🚀

Prompt

Matriz de Pontuação

ChatGPT

Matriz de Pontuação – RFP de Qualidade de Software

Esta matriz deve ser utilizada para avaliação objetiva e comparativa das propostas recebidas no RFP.

---

1. Modelo de Pontuação

Escala padrão (0 a 5):

• 0 – Não atende / Não respondido
• 1 – Atende minimamente, sem evidências
• 2 – Atende parcialmente, com riscos
• 3 – Atende adequadamente
• 4 – Atende bem, com boas práticas comprovadas
• 5 – Atende plenamente, com evidências robustas e diferenciais claros

---

2. Pesos por Atributo de Qualidade

#	Atributo	Peso (%)
1	Funcionalidade	8
2	Performance / Eficiência	8
3	Confiabilidade	7
4	Usabilidade	5
5	Segurança	10
6	Manutenibilidade	6
7	Portabilidade	3
8	Escalabilidade	8
9	Disponibilidade	7
10	Interoperabilidade	5
11	Testabilidade	6
12	Reusabilidade	4
13	Robustez	4
14	Responsividade	3
15	Conformidade com Padrões	4
16	Auditabilidade	3
17	Configurabilidade	3
18	Modularidade	3
19	Flexibilidade	4
20	Integridade	6

Total: 100%

---

3. Estrutura de Avaliação por Atributo

Cada atributo possui 5 perguntas. A pontuação final do atributo é calculada pela média das perguntas multiplicada pelo peso.

Fórmula:
Pontuação do Atributo = (Soma das notas / 25) × Peso

---

4. Exemplo de Avaliação – Segurança

Pergunta	Nota (0–5)
Autenticação e autorização	4
Proteção contra OWASP Top 10	5
Proteção de dados sensíveis	4
Gestão de segredos	3
Testes de segurança	4

Soma: 20
Pontuação Segurança: (20 / 25) × 10 = 8,0 pontos

---

5. Critérios de Evidência Obrigatórios

Para notas 4 ou 5, o fornecedor deve apresentar pelo menos um dos itens abaixo:

• Diagramas arquiteturais
• Exemplos de código ou repositórios
• Relatórios de testes automatizados
• Prints ou links de pipelines CI/CD
• Casos reais de uso em produção

---

6. Classificação Final das Propostas

Faixa de Pontuação	Classificação
85 – 100	Excelente / Recomendado
70 – 84	Bom / Recomendado com ressalvas
55 – 69	Regular / Alto risco
< 55	Não recomendado

---

7. Critérios Eliminatórios (Opcional)

A proposta pode ser automaticamente desclassificada se:

• Não atender à stack obrigatória (Angular, Java, PostgreSQL)
• Não adotar arquitetura de micro-serviços
• Não possuir testes automatizados
• Não atender requisitos mínimos de segurança

---

Observação: Esta matriz pode ser ajustada conforme criticidade do negócio ou setor regulatório.

Prompt

Mapear cada pergunta para ISO/IEC 25010, NFRs ou Arquitetura de Referência

ChatGPT

Mapeamento das Perguntas do RFP

Este documento mapeia cada tópico do questionário de RFP para:

• ISO/IEC 25010 (características e subcaracterísticas)
• NFRs (Non-Functional Requirements)
• Arquitetura de Referência baseada em micro-serviços, API First e micro-frontends

---

1. Funcionalidade (Functional Suitability)

ISO/IEC 25010: Functional suitability (Completeness, Correctness, Appropriateness)

NFRs:

• NFR-FUNC-01: A solução deve atender integralmente aos requisitos de negócio
• NFR-FUNC-02: APIs devem refletir corretamente as regras de negócio

Arquitetura de Referência:

• API First com OpenAPI
• Contratos versionados
• Bounded Contexts (DDD)

---

2. Performance / Eficiência

ISO/IEC 25010: Performance efficiency (Time behavior, Resource utilization, Capacity)

NFRs:

• NFR-PERF-01: Tempo de resposta < X ms
• NFR-PERF-02: Suporte a N usuários simultâneos

Arquitetura de Referência:

• Cache distribuído
• Load balancing
• Observabilidade (APM)

---

3. Confiabilidade (Reliability)

ISO/IEC 25010: Reliability (Maturity, Availability, Fault tolerance, Recoverability)

NFRs:

• NFR-REL-01: Sistema deve tolerar falhas parciais
• NFR-REL-02: MTTR < X minutos

Arquitetura de Referência:

• Circuit breaker
• Retry / Timeout
• Health checks

---

4. Usabilidade (Usability)

ISO/IEC 25010: Usability (Learnability, Operability, User error protection)

NFRs:

• NFR-UX-01: Interface intuitiva
• NFR-UX-02: Acessibilidade WCAG 2.1

Arquitetura de Referência:

• Design System
• Micro-frontends Angular

---

5. Segurança (Security)

ISO/IEC 25010: Security (Confidentiality, Integrity, Non-repudiation, Accountability)

NFRs:

• NFR-SEC-01: Autenticação forte
• NFR-SEC-02: Proteção contra OWASP Top 10

Arquitetura de Referência:

• OAuth2 / OIDC
• API Gateway
• Secrets Manager

---

6. Manutenibilidade (Maintainability)

ISO/IEC 25010: Maintainability (Modularity, Reusability, Analyzability, Modifiability)

NFRs:

• NFR-MAN-01: Facilidade de correção
• NFR-MAN-02: Baixo acoplamento

Arquitetura de Referência:

• Clean Architecture
• Hexagonal Architecture

---

7. Portabilidade (Portability)

ISO/IEC 25010: Portability (Adaptability, Installability)

NFRs:

• NFR-PORT-01: Execução em múltiplos ambientes

Arquitetura de Referência:

• Containers Docker
• Infraestrutura como código

---

8. Escalabilidade (Scalability)

ISO/IEC 25010: Performance efficiency / Reliability

NFRs:

• NFR-SCAL-01: Escala horizontal automática

Arquitetura de Referência:

• Stateless services
• Auto scaling

---

9. Disponibilidade (Availability)

ISO/IEC 25010: Reliability (Availability)

NFRs:

• NFR-AVL-01: SLA >= 99.X%

Arquitetura de Referência:

• Multi-zone deployment
• Failover automático

---

10. Interoperabilidade (Interoperability)

ISO/IEC 25010: Compatibility (Interoperability)

NFRs:

• NFR-INT-01: Integração via APIs REST

Arquitetura de Referência:

• RESTful APIs
• Event-driven architecture

---

11. Testabilidade (Testability)

ISO/IEC 25010: Maintainability (Testability)

NFRs:

• NFR-TEST-01: Cobertura mínima de testes

Arquitetura de Referência:

• CI/CD
• Test Pyramid

---

12. Reusabilidade (Reusability)

ISO/IEC 25010: Maintainability (Reusability)

NFRs:

• NFR-REU-01: Reuso de componentes

Arquitetura de Referência:

• Shared libraries
• Component libraries

---

13. Robustez (Robustness)

ISO/IEC 25010: Reliability / Security

NFRs:

• NFR-ROB-01: Tolerância a erros

Arquitetura de Referência:

• Defensive programming
• Chaos engineering

---

14. Responsividade (Responsiveness)

ISO/IEC 25010: Performance efficiency (Time behavior)

NFRs:

• NFR-RESP-01: Feedback imediato ao usuário

Arquitetura de Referência:

• Async processing
• Lazy loading

---

15. Conformidade com Padrões

ISO/IEC 25010: Compatibility / Security / Maintainability

NFRs:

• NFR-COMP-01: Aderência a padrões

Arquitetura de Referência:

• Arquitetura corporativa
• Standards REST

---

16. Auditabilidade (Auditability)

ISO/IEC 25010: Security (Accountability)

NFRs:

• NFR-AUD-01: Rastreabilidade completa

Arquitetura de Referência:

• Centralized logging
• SIEM

---

17. Configurabilidade (Configurability)

ISO/IEC 25010: Portability / Maintainability

NFRs:

• NFR-CONF-01: Configuração externa

Arquitetura de Referência:

• Config Server
• Feature toggles

---

18. Modularidade (Modularity)

ISO/IEC 25010: Maintainability (Modularity)

NFRs:

• NFR-MOD-01: Independência de módulos

Arquitetura de Referência:

• Micro-serviços
• Micro-frontends

---

19. Flexibilidade (Flexibility)

ISO/IEC 25010: Maintainability / Portability

NFRs:

• NFR-FLEX-01: Facilidade de evolução

Arquitetura de Referência:

• Extensibility points
• API versioning

---

20. Integridade (Integrity)

ISO/IEC 25010: Security (Integrity) / Reliability

NFRs:

• NFR-DATA-01: Integridade transacional

Arquitetura de Referência:

• ACID / Saga
• Data validation

---

Resultado: Cada pergunta do RFP agora está diretamente conectada a normas ISO, NFRs mensuráveis e decisões arquiteturais claras, facilitando avaliação técnica, governança e auditoria.

Questionário de RFP – Avaliação de Qualidade de Software

Stack obrigatória: Angular (Frontend / Micro-frontends), Java (Backend / Micro-serviços), PostgreSQL (Banco de Dados)
Arquitetura: Micro-serviços, API First, Micro-frontend
Qualidade: Testes automatizados, segurança, escalabilidade e boas práticas arquiteturais

---

1. Funcionalidade (Functional Suitability)

1. Como a solução garante rastreabilidade completa entre requisitos funcionais e APIs (API First)?
2. Como os contratos de API (OpenAPI/Swagger) são versionados e validados?
3. Como mudanças de requisitos impactam micro-serviços já em produção?
4. Como é garantida a consistência funcional entre micro-frontends?
5. Quais mecanismos asseguram que funcionalidades críticas sejam priorizadas e protegidas?

2. Performance / Eficiência

1. Como a arquitetura garante baixo tempo de resposta sob alta concorrência?
2. Quais estratégias de cache são utilizadas (frontend, backend, banco)?
3. Como são realizados testes de performance e stress?
4. Como o PostgreSQL é otimizado para alto volume de leitura/escrita?
5. Como gargalos entre micro-serviços são identificados?

3. Confiabilidade (Reliability)

1. Como falhas em um micro-serviço não impactam todo o sistema?
2. Quais padrões de resiliência são adotados (circuit breaker, retry, timeout)?
3. Como é tratada a recuperação automática de falhas?
4. Qual o histórico de estabilidade da solução em ambientes produtivos?
5. Como erros são registrados e monitorados?

4. Usabilidade (Usability)

1. Como o Angular é utilizado para garantir consistência visual entre micro-frontends?
2. Como princípios de UX e acessibilidade são aplicados?
3. Como feedback do usuário é coletado e incorporado?
4. Como erros são apresentados de forma clara ao usuário final?
5. A solução é responsiva e compatível com múltiplos dispositivos?

5. Segurança (Security)

1. Como é implementada autenticação e autorização (OAuth2, OpenID Connect)?
2. Como as APIs são protegidas contra ataques (OWASP Top 10)?
3. Como dados sensíveis são protegidos no PostgreSQL?
4. Como segredos e credenciais são gerenciados?
5. Como testes de segurança são executados (SAST, DAST)?

6. Manutenibilidade (Maintainability)

1. Como o código Java é organizado para facilitar manutenção?
2. Quais padrões arquiteturais são utilizados?
3. Como o acoplamento entre micro-serviços é minimizado?
4. Como a documentação técnica é mantida atualizada?
5. Qual o tempo médio para corrigir defeitos?

7. Portabilidade (Portability)

1. A solução é containerizada (Docker)?
2. Como é garantida a execução em diferentes ambientes (cloud/on‑premises)?
3. Como dependências externas são abstraídas?
4. Como o Angular é configurado para múltiplos ambientes?
5. Existe dependência de fornecedor (vendor lock-in)?

8. Escalabilidade (Scalability)

1. Como micro-serviços escalam horizontalmente?
2. Como o banco PostgreSQL é escalado?
3. Como picos de acesso são tratados?
4. Como micro-frontends escalam independentemente?
5. Como limites de capacidade são monitorados?

9. Disponibilidade (Availability)

1. Qual o SLA garantido da solução?
2. Como é garantida alta disponibilidade dos serviços?
3. Existe estratégia de failover?
4. Como janelas de manutenção são tratadas?
5. Como indisponibilidades são comunicadas?

10. Interoperabilidade (Interoperability)

1. Como APIs REST seguem padrões de mercado?
2. Existe suporte a integração via eventos/mensageria?
3. Como versionamento de APIs evita quebra de contratos?
4. Como sistemas legados são integrados?
5. Como erros de integração são tratados?

11. Testabilidade (Testability)

1. Qual a cobertura mínima de testes automatizados?
2. Existem testes unitários, de integração e end‑to‑end?
3. Como testes são executados em CI/CD?
4. Como micro-frontends são testados isoladamente?
5. Como dados de teste são gerenciados?

12. Reusabilidade (Reusability)

1. Como componentes Angular são reutilizados?
2. Existem bibliotecas comuns entre micro-serviços?
3. Como APIs são projetadas para reutilização?
4. Como duplicação de código é evitada?
5. Existem guidelines formais de reutilização?

13. Robustez (Robustness)

1. Como o sistema lida com entradas inválidas?
2. Como falhas externas são isoladas?
3. Como exceções são tratadas no backend?
4. Como o sistema se comporta sob condições extremas?
5. Existem testes de caos (chaos testing)?

14. Responsividade (Responsiveness)

1. Como o frontend garante carregamento rápido?
2. Como chamadas assíncronas são tratadas?
3. Existe uso de lazy loading?
4. Como o tempo de resposta é monitorado?
5. Como SLAs de resposta são garantidos?

15. Conformidade com Padrões

1. Quais padrões arquiteturais são seguidos?
2. A solução segue normas ISO ou equivalentes?
3. Como conformidade é auditada?
4. Como boas práticas de REST são aplicadas?
5. Existem padrões internos documentados?

16. Auditabilidade (Auditability)

1. Como logs de auditoria são registrados?
2. É possível rastrear ações por usuário?
3. Logs são imutáveis?
4. Existe integração com SIEM?
5. Como relatórios de auditoria são gerados?

17. Configurabilidade (Configurability)

1. Como configurações são externalizadas?
2. Existe separação entre código e configuração?
3. Como mudanças de configuração são aplicadas?
4. Existe versionamento de configurações?
5. Configurações são seguras?

18. Modularidade (Modularity)

1. Como micro-serviços são delimitados?
2. Como micro-frontends são independentes?
3. Existe baixo acoplamento entre módulos?
4. Como dependências são gerenciadas?
5. Como módulos podem evoluir isoladamente?

19. Flexibilidade (Flexibility)

1. Como a arquitetura suporta novas funcionalidades?
2. Como novos micro-serviços são adicionados?
3. Como mudanças de negócio impactam o sistema?
4. Como APIs evoluem sem impacto?
5. Existe suporte a extensões futuras?

20. Integridade (Integrity)

1. Como a integridade dos dados é garantida no PostgreSQL?
2. Como transações distribuídas são tratadas?
3. Existe validação consistente de dados?
4. Como corrupção de dados é detectada?
5. Existem mecanismos de rollback e versionamento?

---

Observação: As respostas devem incluir evidências técnicas, diagramas arquiteturais e exemplos práticos.

Top 101 sample questions to use in any RFP. This list includes a range of questions from general information to very specific inquiries. While closed-ended questions are easiest to score, open-ended questions evoke thoughtful, creative answers. Ideally, your RFP should contain a balance of both.

Many of these questions are best suited to an RFP or RFI rather than an RFQ. The sample RFP questions included below are most useful for indirect or strategic sourcing projects where the primary goal is overall, long-term partnership value.

General questions

These are run-of-the-mill questions that appear in almost every RFP. Nonetheless, these sample RFP questions are important to the process. Generally, these questions are not a factor in your ultimate decision, but exist to provide background information about your vendors.

1. Who will serve as the primary contact for this RFP? Please include the primary contact’s name, title, direct phone number, and email address. Indicate if there will be any secondary contacts and specify their roles in the RFP process.

2. Please provide a company overview. Share a brief history of your company, including founding year, key milestones, and core business areas. Highlight your company’s unique value proposition and how it distinguishes itself from competitors.

3. Where is your company located? Provide the address of your headquarters and note any significant regional or international offices. Explain how your company’s location impacts its service delivery or product distribution.

4. How long have you been in business? State the number of years your company has been operational. If applicable, mention any predecessor entities or major pivots in your business model.

5. Please provide your company’s mission and/or vision statement. Share your company’s mission and vision statements. Explain how these guide your business strategies, culture, and stakeholder engagement.

6. Describe the company structure. (Private, public, partnership, etc) Elaborate on your company’s legal structure. If public, mention the stock exchange and ticker symbol. If private, indicate ownership composition. For partnerships, describe the nature of the partnership and key partners.

7. How many full-time, part-time and contract employees do you have? (Please provide breakdown) Offer a current employee count, categorizing staff into full-time, part-time, and contract workers. Highlight any significant fluctuations in staffing levels over the past year and reasons for these changes.

8. What awards or recognition has your company received in the last three years? List awards and recognitions, specifying the awarding bodies and the criteria for each accolade. Describe how these awards reflect your company’s strengths and achievements.

9. Is your company affiliated with any industry or professional associations? Name the industry or professional associations your company is a member of. Explain the significance of these affiliations to your business operations and how they keep your company informed and competitive.

10. What licenses or certifications does your company hold? Detail the specific licenses and certifications your company has obtained, including the issuing organizations and validity periods. Explain how these credentials ensure compliance and elevate your company’s qualifications in your industry.

11. Please provide a product or service overview and description. Offer a detailed catalog of your products or services, including key features, benefits, and intended users or markets. Highlight any unique selling points or proprietary technology.

12. Describe your plans for growth over the next 3 years. Share your strategic growth plans, including market expansion, product or service development, and any planned mergers or acquisitions. Discuss anticipated challenges and how your company intends to address them.

Customer questions

This section of sample RFP questions addresses the vendors’ current customers. Again, these questions are informative, but they likely won’t be pivotal in your decision. After all, what’s the ideal answer to a question like, “How many customers do you serve?” Accordingly, they may not have an assigned value in your weighted scoring.

14. What is your target customer base? Include demographic, geographic, and psychographic characteristics of your target customer base. Explain how your products or services meet the specific needs and preferences of this group.

15. How many customers do you currently serve? Provide the total number of active customers you serve. If possible, break down this number by major segments or markets to offer a clearer picture of your customer distribution.

16. What is your customer retention rate? Share your customer retention rate over a specific period, typically annually. Discuss any strategies or practices your company employs to maintain high retention rates.

17. Who are your five biggest customers? List your five largest customers without breaching any confidentiality agreements. Briefly describe the nature of services or products provided to these customers and the duration of your relationship.

18. What percentage of your revenue comes from the top three accounts? List your five largest customers without breaching any confidentiality agreements. Briefly describe the nature of services or products provided to these customers and the duration of your relationship.

19. How long is your average customer relationship? Provide the average duration of customer relationships across your client base. Highlight any key factors that contribute to sustaining long-term relationships with your clients.

20. Are any of our primary competitors customers? (Competitor 1, Competitor 2, Competitor 3) Confirm if any of your clients also do business with our identified competitors. Discuss how you differentiate your offerings to maintain these customer relationships in a competitive market.

21. Please provide contact information for three customer references. Supply the names, titles, companies, phone numbers, and email addresses for three references. Choose references that reflect a range of experiences and successes with your company’s products or services.

22. On average, what ROI do customers report after using your service/product? Describe the typical return on investment your customers experience, supported by any statistics or case studies. Explain the factors that contribute to these outcomes and how you measure ROI for your clients.

Competitor questions

While some procurement managers shy away from asking vendors about their competitors, it’s worth considering. RFP questions like this can reveal new vendors that you may have missed. In addition, the way that vendors respond is often revealing.

For instance, do they answer candidly or vaguely? Do they tailor their list of competitors to your needs and use case? How well do they keep up with trends within the industry? All interesting questions when you’re considering a long-term relationship.

22. Who are your top three competitors? Identify your top three competitors in the market. Provide a brief overview of each competitor, including their market share, key strengths, and how your offerings compare to theirs.

23. What are your primary competitive differentiators? Outline the key factors that distinguish your products or services from those of your competitors. This could include aspects such as unique technology, customer service excellence, price competitiveness, or innovation in product development.

24. Why should we work with you instead of one of your competitors? Highlight the specific advantages and benefits that your company offers over competitors. Focus on what makes your approach or solutions more effective, efficient, or valuable to clients like us.

25. Are there alternative solutions that could better meet our needs? Discuss any alternative solutions or approaches, including those offered by competitors, that might also meet our needs. Explain why your solution is preferable, considering factors such as cost, scalability, or alignment with our strategic goals.

26. Describe current industry trends and how your company keeps us on the leading edge. Provide an analysis of current trends impacting your industry and how your company is positioned to leverage these trends for innovation and growth. Explain how your solutions or services are evolving in response to these trends to ensure clients remain competitive.

Functionality and deliverables questions

Now we’re into the heavy-hitting questions. Indeed, these RFP questions carry significant weight in your RFP scoring process. Depending on your priorities, this section may be the most important and therefore, the highest value in your scoring.

These sample RFP questions should be customized to meet the needs of your project. For instance, along with question 28, consider including a table with a list of all of your minimum requirements. Also add a corresponding column that allows prospective vendors to indicate their ability to comply with each requirement with yes, no or partially.

27. Please indicate your ability to meet our RFP requirements. Describe your company’s capability and experience in fulfilling similar RFP requirements. Include examples of past projects or solutions that demonstrate your ability to meet or exceed the specified criteria.

28. Provide a sample timeline for our outlined deliverables. Offer a provisional timeline that outlines major milestones, phases, and estimated completion dates for the deliverables specified in the RFP. Mention any assumptions or dependencies that could impact the timeline.

29. Do you recommend any customization or additional features to achieve our goals? Suggest any customizations or additional features that could enhance the effectiveness or efficiency of the proposed solution in meeting our goals. Explain the benefits and any potential impact on timeline or budget.

30. What self-service reporting tools are available to us? Detail the self-service reporting tools your solution offers, including features, capabilities, and how these tools can help us in monitoring performance, generating insights, and making data-driven decisions.

31. How do you determine your roadmap and/or product strategy? Explain the process for defining your product roadmap and strategy, including how customer feedback, market trends, and technological advancements are incorporated. Discuss how you prioritize features or enhancements.

32. What integrations are available? List the integrations currently available with your product or service, including common software, platforms, or APIs. Describe how these integrations can enhance functionality and efficiency for clients.

33. When are updates and enhancements delivered to customers? Describe your schedule for rolling out updates and enhancements, including any standard maintenance windows or version release cycles. Mention how clients are notified and supported through updates.

34. What is your company’s approach to project management? Outline your project management methodology, including how projects are planned, monitored, and reported. Highlight the tools and practices you use to ensure projects stay on track and stakeholders are kept informed.

35. How often are projects completed on time and within budget? Share statistics or percentages that reflect your track record for completing projects on time and within budget. Discuss any measures or practices you have in place to manage timelines and costs effectively.

36. What action, participation or documentation is required from our organization to ensure timely implementation? Detail the specific actions, participation, or documentation needed from our side to facilitate a smooth and timely implementation process. Include any critical milestones where our input or decision-making is essential.

Experience and approach questions

This section of RFP questions is designed to inspect each vendor’s qualifications. If you already performed a request for qualifications (RFQ), and narrowed your vendor selection to only those that pre-qualified, you may decide to omit these questions.

37. What experience do you have working with organizations like ours? Outline your history and experience in working with organizations of our size, industry, and complexity. Highlight any specific challenges you have addressed and how your solutions benefited similar clients.

38. Please provide any relevant case studies. Share case studies that detail your work with organizations similar to ours, including the objectives, strategies employed, outcomes, and any measurable impact your services or products had on their success.

39. What resources will be dedicated to our account? Describe the team composition and resources that will be allocated to our account, including roles, expertise, and how they will contribute to achieving our objectives.

40. Provide brief biographies and project experience for primary contacts assigned to our account. Offer brief biographies of the key personnel who will be directly involved with our account, highlighting their qualifications, relevant experience, and past projects that demonstrate their capability to manage and deliver on our needs.

41. How often will you report our progress and results? Specify the frequency and format of progress and results reporting. Explain how these reports will provide insights into the achievements against KPIs and objectives.

42. What technology do you leverage to ensure excellent customer communication and experience? Detail the technologies and platforms you use to facilitate seamless communication, project management, and customer service. Explain how these tools enhance the overall customer experience and project success.

43. Provide a list of the standard report options, what each includes and available formats. List the standard reports available to clients, including a description of the information each report covers, such as performance metrics, progress updates, and insights. Mention the formats in which these reports can be delivered.

44. How are usage and performance reports provided? Explain the process for generating and delivering usage and performance reports, including the frequency of these reports and how they can be accessed by clients.

45. What KPIs do you track and report? Identify the key performance indicators (KPIs) you typically track and report on for projects similar to ours. Describe how these KPIs align with project objectives and how they are used to gauge success.

46. Describe your approach to continuous process improvement. Outline your methodology for identifying areas for improvement, implementing changes, and measuring the impact of those changes. Discuss how client feedback and performance data drive your process improvement efforts.

Customer success questions

Often overlooked, customer success questions are crucial to selecting the right vendor for long-term engagements. Including these sample RFP questions gives you a sense of what it’s like to work with this vendor, what you can expect and how you’ll stay in touch after the contract is executed.

47. On average, how long does implementation take? Provide an estimated timeframe for the full implementation of your solution or service from initiation to completion. Highlight any factors that could influence this timeline.

48. What is your averaged time to value (TtV)? Share the average time customers typically start seeing value from your solution or service. Explain the stages in the implementation or usage process where value becomes evident.

49. Describe your training and onboarding process. Outline the steps involved in your training and onboarding process for new clients, including any materials, workshops, webinars, or support provided to ensure a smooth transition and quick adoption of your services or products.

50. What is required from a customer to ensure success? Specify the inputs, commitments, or actions required from the customer’s side to guarantee the successful implementation and optimal use of your solution or service.

51. Do you have a change management process? Describe your approach to managing changes during the project lifecycle, including how changes are identified, assessed, approved, and communicated to ensure minimal disruption and maintain alignment with project goals.

52. What is a successful customer journey to your organization? Define what a successful customer journey looks like from initial engagement through to long-term partnership, including key milestones and outcomes that signify success.

53. Do you conduct quarterly business reviews with customers? Confirm whether you engage in regular business reviews with clients, focusing on the objectives, frequency, and content of these reviews to ensure ongoing alignment and address any areas for improvement.

54. How do you provide updates, track progress and ensure our success? Explain the mechanisms in place for providing regular updates and tracking progress against agreed objectives. Discuss how you collaborate with clients to adjust strategies and actions to ensure success.

55. Please provide a list of self-service tools or resources that are available after onboarding. List the self-service tools and resources, such as knowledge bases, user forums, FAQs, and online training modules, that clients can access independently to resolve issues or enhance their use of your product or service.

56. How do you manage customer requests, complaints, concerns and feedback? Detail the process for handling customer interactions, from logging requests or complaints to resolution and follow-up. Highlight how feedback is incorporated into your continuous improvement efforts.

57. ​​Do you use in-house or outsourced resources for customer support? Clarify whether your customer support function is managed in-house or outsourced, including the rationale for your approach and how it benefits the quality and responsiveness of your support services.

Pricing questions

What is it going to cost? There are a lot of ways to ask and this list of RFP questions will help you gather the right information. Similar to other RFP questions, these should be customized to meet the needs of your current project.

58. Provide a pricing estimate based on the scope described. Offer a comprehensive pricing estimate tailored to the specific scope outlined in the RFP, including both initial setup costs and ongoing fees. Ensure transparency in how the estimate is calculated to provide a clear understanding of the value provided.

59. Please describe your current pricing model/methodology. Detail the approach you use to structure pricing for your products or services, whether it’s subscription-based, tiered, usage-based, or a custom pricing model. Explain how this model aligns with the value delivered to customers.

60. What are the itemized one-time, startup costs and recurring annual/monthly costs? Break down the costs associated with your solution or service into one-time, startup fees and ongoing, recurring charges. Itemize these costs to include any setup, licensing, or initial training expenses.

61. Please list all services and features included in the proposed pricing. Provide a detailed list of all services, features, and functionalities included within the quoted pricing, highlighting any key features that differentiate your offering from competitors.

62. What limits are imposed upon users, training hours, professional services and data storage? Specify any limitations that apply to the use of your service or product, such as the number of users, hours of training included, access to professional services, and data storage capacity.

63. At what level do you provide volume discounts? Explain the thresholds or criteria for volume discounts within your pricing structure. Clarify how these discounts are applied and the level of commitment required to qualify for them.

64. Describe your upgrade process if we need to increase our scope. Outline the process for adjusting the scope of service, including how upgrades can be initiated, the evaluation of additional needs, and how changes are priced and implemented.

65. What are your cancellation/renewal terms? Detail the terms and conditions surrounding contract cancellations and renewals, including any notice periods, fees, or conditions that must be met for either action.

66. How do you ensure your pricing remains competitive? Discuss the strategies you employ to maintain competitive pricing, including regular market analysis, value-based pricing practices, and how you balance quality and cost to offer compelling value to customers.

Risk management questions

Risk management is an important part of the procurement process in general as well as the RFP process specifically. Thus, risk questions like these should be included in your RFP or sent as part of a separate vendor risk assessment.

67. Is your organization GDPR compliant? Confirm your organization’s compliance with the General Data Protection Regulation (GDPR), detailing the measures and processes in place to protect personal data and ensure privacy rights are respected.

68. Describe your regulatory compliance process. Outline the framework and processes your organization follows to stay compliant with relevant regulations and standards within your industry. Highlight how you monitor changes in legislation and implement necessary adjustments.

69. Are there any pending legal issues or complaints against your company? Disclose any current legal disputes or formal complaints filed against your company, providing context and how these issues are being addressed or resolved.

70. Share statistics about technology stability/reliability and down times. Provide data on the stability and reliability of your technology solutions, including average uptime statistics and records of significant downtime incidents, along with explanations of how these were mitigated.

71. Please provide your business continuity and emergency preparedness plan. Share details of your business continuity and emergency response strategies, including procedures for data backup, disaster recovery, and ensuring operational resilience in the face of unforeseen events.

72. How often does the company update and test the continuity and preparedness plans? State the frequency at which your business continuity and emergency preparedness plans are reviewed, updated, and tested to ensure they remain effective and relevant.

73. Is your organization equipped to work remotely? Describe your organization’s capabilities and infrastructure to support remote work, including technology tools, security measures, and policies in place to maintain productivity and collaboration.

74. How do you manage price volatility with your suppliers? Explain the strategies or mechanisms you employ to manage and mitigate the impact of price volatility from your suppliers, ensuring stable pricing and supply chain continuity.

75. Describe your approach to staff retention. What is the average turnover rate for the last five years? Detail your strategies for retaining staff, including employee engagement, development opportunities, and workplace culture initiatives. Provide the average turnover rate for your organization over the past five years, offering insight into the effectiveness of your retention efforts.

Data security questions

Ensuring the integrity of your data is essential no matter what you’re purchasing. While some RFPs group data security with vendor risk, it can be helpful to give each its own section. Supplement these sample RFP questions with regular security risk assessments.

76. Describe your backup and data recovery policy. Detail your organization’s approach to data backup and recovery, including the frequency of backups, types of data backed up, storage locations, and the process for restoring data in the event of data loss or corruption.

77. Where do you host your software and customer data? Specify the hosting environment for your software and customer data, including whether it’s on-premises, cloud-based, or a hybrid model. Mention the geographical location of your data centers and any relevant security certifications they hold.

78. Are you SOC compliant? ISO certified? If so, what is your current level? Confirm your compliance with SOC (Service Organization Control) and ISO (International Organization for Standardization) standards, specifying which types of SOC reports you have (e.g., SOC 2 Type II) and which ISO certifications (e.g., ISO 27001), including the level or version of these certifications.

79. What are the results of your most recent penetration test? Share the findings from your most recent penetration testing, including the scope of the test, any vulnerabilities identified, and the steps taken to address these vulnerabilities.

80. Describe how security vulnerabilities are identified and mitigated. Outline the processes and tools in place for identifying and mitigating security vulnerabilities, including regular security audits, vulnerability scanning, and the protocol for responding to discovered vulnerabilities.

81. Is our data accessed and used by your company? Clarify the circumstances under which your company accesses and uses customer data, detailing the purposes for such access and the measures in place to ensure data privacy and security.

82. Have you experienced downtime in the last two years? If so, how long were customers impacted? Disclose any instances of significant downtime your service has experienced in the past two years, including the duration of the outage, the cause, and how it was resolved.

83. What are your data import and export capabilities? Describe the capabilities and processes for importing data into and exporting data out of your system, including supported formats, tools, and any limitations or restrictions on data movement.

Sustainability questions

These RFP questions cover vendor sustainability. Indeed, partnering with vendors who share your company’s values is increasingly important to maintaining your brand reputation. Asking these questions in your RFP ensures your ongoing sustainability efforts and initiatives won’t be derailed after you’ve signed a contract.

84. Do you have a corporate responsibility policy? If so, please provide it. Share your corporate responsibility policy, outlining your commitments to ethical business practices, community engagement, environmental sustainability, and how these commitments are integrated into your business operations.

85. What sustainability accreditations and certifications do you hold? List any sustainability-related accreditations and certifications your organization has achieved, including details about the issuing bodies and the standards or criteria met to obtain these credentials.

86. Who in your business monitors, manages and reports sustainability efforts and impacts? Identify the team or individual responsible for overseeing your sustainability initiatives, including their role in monitoring, managing, and reporting on the environmental and social impacts of your business activities.

87. Do you measure the sustainability performance of your vendors and subcontractors? Explain the process for evaluating the sustainability performance of your vendors and subcontractors, including any criteria or standards they are expected to meet as part of your supply chain.

88. Do you track, report and manage your use of energy, water and chemicals? Describe the systems and practices in place for tracking, reporting, and managing the consumption and impact of energy, water, and chemicals in your operations.

89. How can we partner with you to enhance environmental sustainability in our mutual supply chain? Suggest ways in which your organization and potential clients can collaborate to improve environmental sustainability within the supply chain, including shared initiatives or programs.

90. Do you use renewable energy? Confirm whether your operations utilize renewable energy sources. Detail the extent of renewable energy use and any future plans to increase this usage.

91. How does your organization give back to or serve your community? Highlight the initiatives and programs your organization participates in to support and give back to local communities, including volunteer efforts, donations, and community service projects.

92. Do you enforce a supplier code of conduct? If so, please provide it. Indicate if your organization has a supplier code of conduct that outlines the ethical, environmental, and social standards expected of your suppliers. Provide a copy or summary of this code.

93. Provide any other company mandates concerning your purchasing philosophy and strategy. Share details about your company’s purchasing philosophy and strategy, including how sustainability, ethical sourcing, and community impact factor into your decision-making and vendor selection processes.

94. Does your organization publish an environmental performance report? Confirm whether your organization publishes an annual or periodic environmental performance report. Describe the type of information included, such as carbon footprint, resource usage, and progress towards sustainability goals, and how it can be accessed.

Diversity and inclusion questions

Procurement teams have a unique power to support diversity initiatives. These RFP questions help your team understand each vendor’s commitment to diversity and inclusion.

95. Please provide any current diversity certifications. List any diversity certifications your organization has received, such as those related to being a minority-owned, woman-owned, veteran-owned, or LGBTQ+-owned business. Include the certifying bodies and the dates of certification.

96. Does your company have a supplier diversity program? If so, please provide. Describe your supplier diversity program, including its objectives, the types of diverse suppliers it targets, and how the program is implemented and managed within your procurement processes.

97. What percentage of your employees are women and/or minorities? Share the current percentage of your workforce that is comprised of women and minorities. If available, provide a breakdown by department or role to give a clearer picture of diversity across the organization.

98. What percentage of senior leadership is women or minorities? Indicate the percentage of your senior leadership team that consists of women and minorities. Discuss any initiatives or goals to increase diversity within leadership positions.

99. Does your organization have a diversity and inclusion goal and how do you track progress? Outline any specific diversity and inclusion goals your organization has set, including the metrics or benchmarks used to track progress towards these goals.

100. Have there been any claims of sexual or general harassment, misconduct or discrimination in the last 5 years? Please provide details, if so. Disclose any incidents of harassment, misconduct, or discrimination reported within the last five years, including the nature of the claims and the outcomes of any investigations or actions taken in response.

101. For last year, what percentage of your company’s procurement spend was with women, minority and veteran-owned businesses? Provide statistics on the percentage of your procurement budget spent with women-owned, minority-owned, and veteran-owned businesses in the last fiscal year, including any targets or goals for future spending with diverse suppliers.