A customer relationship management platform helps organisations manage their customers, sales opportunities, communications, and business processes. What appears to be a collection of contact records is usually a much broader system involving configurable data models, permissions, search, automation, reporting, and third-party integrations.
Designing a CRM platform is a useful system design interview problem because it combines conventional business data with several difficult engineering challenges. The system must isolate data between organisations, support extensive customisation, enforce detailed permissions, and process background workflows reliably.
In this post, we’ll design a scalable CRM platform, starting with its requirements before exploring the architecture, data model, and most important trade-offs.
A system design interview may begin with a broad prompt:
Design a CRM platform like Salesforce or HubSpot.
A complete CRM product could include sales, marketing, customer support, billing, email campaigns, analytics, artificial intelligence, and hundreds of integrations. Attempting to design everything would make the interview unmanageable.
For this design, we will focus on the core sales experience. Organisations can manage accounts, contacts, leads, and opportunities. Users can record emails, calls, meetings, and notes against those records. The platform also supports search, configurable fields, basic workflow automation, and reporting.
The CRM will be a multi-tenant software-as-a-service platform. Many organisations use the same underlying infrastructure, but each organisation’s data must remain logically isolated and visible only to authorised users.
This multi-tenant model influences the data architecture, security controls, caching strategy, and almost every query the system performs.
The first step is to define what users need to accomplish.
A sales representative should be able to create and update leads, contacts, companies, and opportunities. They should be able to record interactions, assign records to colleagues, move opportunities through sales stages, and find relevant customer information quickly.
Managers should be able to view their team’s pipeline, configure sales processes, create dashboards, and report on performance. Administrators need to manage users, roles, permissions, custom fields, and integrations.
The initial design will not attempt to include every possible CRM feature. Large-scale marketing campaigns, customer-support ticketing, billing, advanced artificial intelligence, and a public application marketplace can be treated as future extensions.
The non-functional requirements are equally important. The platform must provide strong tenant isolation, reliable storage, low-latency record access, and a complete audit history for important changes. It must support organisations of different sizes, from small businesses with a few users to enterprises containing millions of customer records.
The platform should remain available if a non-essential component fails. A temporary problem with reporting or email synchronisation should not prevent users from opening or updating customer records.
The system should be organised around the activities CRM users perform most frequently.
One important workflow begins when a sales representative creates a lead. The representative records the prospect’s details, adds notes, schedules follow-up tasks, and updates the lead as the relationship develops. If the prospect becomes qualified, the lead may be converted into an account, contact, and sales opportunity.
Another workflow involves managing an opportunity. Users update its expected value, sales stage, probability, and expected close date. Each change contributes to pipeline reports and may trigger automated actions.
Users also need a complete activity timeline. Emails, calls, meetings, notes, and field changes should appear in chronological order against the relevant customer record.
Search is another essential workflow. A user may remember only part of a person’s name, company, email address, or telephone number. Search should return relevant results quickly while still respecting tenant boundaries and user permissions.
These workflows show that a CRM is both transactional and analytical. Users expect immediate updates to individual records, while managers expect dashboards and reports covering large collections of data.
Back-of-the-envelope calculations help identify where the system may encounter pressure.
Suppose the platform supports 100,000 organisations and 10 million registered users. A small organisation may store only a few thousand records, while a large enterprise may have tens of millions.
If two million users are active each day and each performs 100 reads or updates, the platform handles approximately 200 million requests per day. This is an average of roughly 2,300 requests per second, although activity will be concentrated during working hours in different regions.
The data volume extends beyond the primary CRM records. Every email, note, task, field update, workflow execution, and audit entry creates additional information. A contact might occupy only a few kilobytes, but its lifetime activity history could become substantially larger.
Most interactive operations affect a single organisation and a relatively small number of records. Reporting, imports, exports, and integration synchronisation can create much heavier workloads and should be isolated from ordinary user requests where possible.
The core data model contains several familiar entities.
An account represents a company or organisation with which the customer has a relationship. A contact represents an individual associated with an account. A lead represents a potential customer who has not yet been qualified, while an opportunity represents a possible sale.
Activities such as emails, calls, meetings, notes, and tasks can be associated with one or more of these records. Users, teams, roles, and sharing rules determine who may view or modify them.
Every record must include a tenant identifier. This identifies the organisation that owns the data and forms a fundamental part of access control, queries, indexes, cache keys, and event messages.
A simplified public API might include:
POST /accounts
GET /accounts/{accountId}
POST /contacts
GET /contacts/{contactId}
POST /leads
POST /leads/{leadId}/convert
POST /opportunities
PATCH /opportunities/{opportunityId}
POST /activities
GET /records/{recordId}/timeline
GET /search?q={query}
POST /reportsThe API should support pagination, filtering, sorting, and selective field retrieval. CRM records can contain many fields, so returning every field for every request would waste bandwidth and increase response times.
Updates should include a version number or timestamp to detect conflicting changes. If two users edit the same opportunity simultaneously, the platform should avoid silently overwriting one user’s work.
Users may access the CRM through a web application, mobile application, administrative portal, or a third-party integration.
All external requests pass through an API Gateway:
Web App ─────────────┐
Mobile App ──────────┼──→ API Gateway
Admin Portal ────────┤ │
External Integrations┘ ├──→ Identity Service
├──→ CRM Record Service
├──→ Activity Service
├──→ Search Service
├──→ Permission Service
├──→ Workflow Service
├──→ Reporting Service
└──→ Integration Service
│
Message Broker
│
┌───────────┼───────────┐
↓ ↓ ↓
Search Index Audit Store AnalyticsThe web application provides the main desktop experience, while the mobile application offers access to contacts, tasks, notes, and opportunities when users are away from their desks. An administrative portal allows authorised users to configure the CRM.
External systems may also use the API to import records, update customer information, or subscribe to changes.
The API Gateway is the public entry point to the platform. It validates authentication tokens, applies rate limits, routes requests, records usage, and enforces limits associated with each organisation’s subscription.
The gateway should not contain CRM business rules. Record validation, permissions, workflow logic, and lead conversion remain the responsibility of the services that own those capabilities.
The Identity Service manages user authentication, sessions, and connections to enterprise identity providers. Large customers may require single sign-on and automated user provisioning.
The Permission Service determines whether a user can view, create, update, delete, export, or share a record. Permissions may depend on the user’s role, team, ownership of the record, its business unit, and organisation-wide sharing rules.
Permission checks are required at the service layer. Hiding a button in the web application is not a security control because a user could call the API directly.
The CRM Record Service owns accounts, contacts, leads, opportunities, and their relationships. It validates record changes and writes them to the primary transactional database.
A smaller implementation might keep these capabilities in one well-structured service. As the platform grows, individual record types or business processes may be separated when they develop different scaling or deployment requirements.
The Activity Service stores calls, meetings, emails, notes, and tasks. It builds the timeline shown against each customer or opportunity.
Activity data can grow much faster than the core customer records. Separating it allows the platform to scale timeline storage and queries without placing the same load on the main CRM database.
The Search Service maintains an index of records that users are allowed to discover. It supports partial names, email addresses, telephone numbers, company names, and custom searchable fields.
Search indexing happens asynchronously after records are created or updated. The results may therefore be slightly behind the transactional database, which is normally acceptable for CRM search.
The Workflow Service executes configurable automation.
An organisation might create a rule that assigns new leads by region, creates a follow-up task when an opportunity changes stage, or sends a notification when a deal remains inactive for several days.
Workflow execution is normally asynchronous. This prevents complex customer-defined automation from delaying ordinary record updates.
The Reporting Service produces tables, charts, dashboards, and exports. These operations can require aggregation across millions of records and should not place heavy analytical queries on the primary transactional database.
Record changes can be streamed into a separate analytical store designed for filtering and aggregation. Dashboards may then be refreshed periodically or updated as new events arrive.
The Integration Service connects the CRM to email providers, calendars, marketing platforms, accounting systems, and other external applications.
It manages credentials, scheduled synchronisation, webhooks, retry policies, and provider-specific rate limits. Separating integrations prevents an unreliable external API from directly affecting core CRM operations.
Services communicate synchronously when an immediate result is required. When a user opens a contact, for example, the platform must retrieve the record and check the user’s permission before returning it.
Asynchronous events are used when other services can react after the main operation has completed. Updating an opportunity might publish an event containing the record identifier, tenant identifier, changed fields, and new version.
The Search Service can use that event to update its index. The Workflow Service can evaluate automation rules, the Audit Service can store a permanent change record, and the Reporting Service can update its analytical data.
This event-driven approach reduces direct dependencies. The CRM Record Service does not need to wait for reporting and search updates before returning a successful response.
Events should not be published only after a database write without additional protection. If the service crashes between saving the record and publishing the event, downstream systems may never learn about the change.
The transactional outbox pattern can prevent this problem. The record update and an outgoing event are saved in the same database transaction. A background publisher then reliably sends the stored event to the message broker.
The most important challenges in this design are multi-tenancy, flexible data models, permissions, automation, and integrations.
Every organisation using the platform is a separate tenant. Its users must never be able to access another tenant’s records.
One approach is to store many tenants in shared database tables and include a tenant identifier on every row. This provides efficient infrastructure usage and works well for a large number of small or medium organisations.
Queries must always include the tenant identifier, and database indexes should normally begin with it. Cache keys, search documents, background jobs, logs, and events must also carry tenant context.
Shared storage increases the importance of defensive controls. A missing filter in one query could expose data across organisations. Repository methods can require tenant context by design, while database row-level security can provide an additional layer of protection.
Very large or regulated customers may require dedicated databases or infrastructure. A hybrid model can keep most tenants in shared clusters while assigning selected customers to isolated deployments.
Tenant placement should be hidden behind a routing layer. Services provide a tenant identifier and receive the correct database connection without needing to know where the organisation’s data is physically stored.
CRM customers frequently want to customise the data model. One organisation may add an industry classification to accounts, while another may add renewal dates, contract values, or regional identifiers.
Creating a new database column for every customer-defined field would be difficult to manage. Storing all custom values in a generic key-value table is flexible, but it can make filtering, indexing, and reporting expensive.
A practical design can combine fixed columns for standard fields with a structured document column for custom values. Frequently queried custom fields may receive generated indexes or be copied into a search and analytics store.
Field definitions are stored as metadata. They describe the field’s name, type, validation rules, permissions, and whether it can be searched or used in reports.
The platform must validate custom values against this metadata. A field defined as a date, number, or restricted choice should behave consistently across the web application, API, imports, search, and reporting.
CRM permissions can become more complicated than simple administrator and user roles.
A sales representative may see records they own, a manager may see records belonging to their team, and an operations user may access all opportunities but not private notes. Individual records may also be shared with selected users.
Calculating every permission from the full hierarchy on each request could be expensive. Frequently used role and team information can be cached, while changes to permissions should invalidate affected entries.
List and search queries present an additional challenge. The system must filter unauthorised records before returning results, not retrieve everything and remove restricted data in the client.
For larger tenants, the platform may create precomputed access mappings or include access-control information in the search index. These approaches improve read performance but make permission changes eventually consistent, so highly sensitive operations may still require a final authoritative check.
Customer-defined workflows must be isolated from interactive requests.
When a record changes, the Workflow Service identifies rules that match the event. It then performs actions such as updating another field, assigning a user, creating a task, calling a webhook, or sending a notification.
A workflow can trigger another record update, which may trigger additional workflows. The system needs execution-depth limits and loop detection to prevent accidental infinite automation.
Each workflow run should have an execution record containing its status, attempts, inputs, and results. Failed actions can be retried when safe, while permanently failed executions can be shown to administrators for investigation.
Idempotency is important because an event may be delivered more than once. Reprocessing the same event should not create duplicate tasks or notifications.
A contact’s activity timeline may combine emails, meetings, calls, notes, tasks, and audit entries stored by different services.
Requesting each source individually whenever a user opens the page could produce slow and unreliable responses. Instead, the Activity Service can maintain a read model containing the timeline entries required by the user interface.
Events from email, calendar, task, and record services are projected into this model. Entries are ordered using their event time and a stable secondary identifier.
The timeline can be paginated using a cursor rather than an offset. Cursor-based pagination performs more consistently when new activities are continually inserted.
Search uses a similar read-optimised model. Transactional services remain the source of truth, while the search index provides fast discovery across standard and custom fields.
CRM platforms frequently exchange large amounts of data with other systems.
Imports should be processed as background jobs rather than inside a single web request. The system stores the uploaded file, validates rows, processes records in batches, and provides progress information to the user.
Individual invalid rows should not necessarily fail the entire import. The result can include a downloadable error report explaining which rows were rejected and why.
Exports also require background processing because a large organisation may request millions of records. Export jobs must use the requesting user’s permissions and should produce temporary, access-controlled download links.
Third-party integrations need similar protection. External APIs can be slow, unavailable, or rate-limited. Integration jobs should use bounded retries, exponential backoff, and checkpoints so they can resume without reprocessing an entire dataset.
Core CRM record operations should continue working if reporting, search, automation, or an external integration becomes unavailable.
Services should run across multiple instances and availability zones. Requests between services need timeouts, bounded retries, and circuit breakers. A slow integration should not exhaust the platform’s request capacity.
The primary database should use replication and automatic failover, supported by tested backups and recovery procedures. Point-in-time recovery can help protect customers against accidental deletion or software defects.
Message consumers should be idempotent because brokers may deliver an event more than once. Repeatedly failing events can be moved to a dead-letter queue for investigation.
The platform should also support optimistic concurrency. A record version is returned when a user retrieves a record and submitted with the update. If another user has already changed it, the system can reject the stale update or ask the user to review the conflict.
This prevents silent data loss when several people edit the same customer or opportunity.
CRM systems contain valuable personal and commercial information, making security a central requirement.
All communication should be encrypted, and sensitive data should be encrypted at rest. Credentials used for integrations must be stored in a dedicated secrets system rather than alongside ordinary CRM data.
The platform should enforce least-privilege access and record important administrative actions. Login attempts, permission changes, exports, integration changes, and record deletions should all produce audit events.
Audit records should be append-only and difficult to alter. They should identify the tenant, user, action, affected record, timestamp, and relevant changes.
Privacy controls may need to support retention periods, deletion requests, data exports, and regional storage requirements. Large organisations may also require single sign-on, multi-factor authentication, IP restrictions, and detailed security logs.
A multi-service CRM requires visibility into both technical health and customer-facing behaviour.
Requests should receive a correlation identifier at the API Gateway so they can be followed across services. Structured logs and distributed traces can then show where a slow or failed request spent its time.
Useful measurements include request latency, error rates, database load, cache hit rates, search indexing delay, queue depth, workflow failures, and integration retry rates.
Tenant-level monitoring is also valuable. A single large import or badly configured workflow should not consume enough resources to affect every customer. Usage quotas and workload isolation can prevent one tenant from overwhelming shared infrastructure.
Business-level measurements provide additional context. The platform can monitor successful record updates, search response times, report generation duration, and the delay between a record change and its appearance in downstream systems.
During the interview, begin by defining the type of CRM being designed. Explain that the initial scope includes accounts, contacts, leads, opportunities, activities, search, workflows, and reporting.
Next, describe the clients and API Gateway before introducing the major backend services. Make it clear that the CRM Record Service owns transactional customer data, while specialised services handle activities, permissions, search, automation, reports, and integrations.
Walk through one important workflow. Lead conversion is a good example because it may create an account, contact, and opportunity while preserving activities and preventing duplicate records. An opportunity update is another useful example because it demonstrates transactional storage, event publication, workflow evaluation, auditing, indexing, and reporting.
The deep dive should focus on the requirements that make a CRM distinctive. Multi-tenant isolation ensures that organisations cannot access one another’s data. Metadata-driven fields provide customisation without creating a different database schema for every customer. Permission checks protect records at both the API and query levels.
Explain the trade-offs rather than presenting every decision as universally correct. Shared databases are cost-efficient but require extremely careful tenant filtering. Separate databases provide stronger isolation but increase operational overhead. Asynchronous indexing improves write performance but means search results can briefly lag behind the source data.
Finish by connecting the architecture back to the original requirements. The system provides fast access to customer records, configurable business processes, secure tenant isolation, reliable event processing, and a path for organisations to grow.
Once the core CRM is working, the platform can expand into marketing automation, customer support, billing, and more advanced sales forecasting.
An ecosystem for third-party applications could allow developers to add new interfaces and workflows. This would require secure application identities, scoped permissions, versioned APIs, webhooks, installation management, and usage limits.
Artificial intelligence could help summarise account activity, draft follow-up messages, identify duplicate records, or recommend the next sales action. These features would need strict controls to prevent users or models from accessing records outside their permissions.
Collaboration could be improved with real-time updates, mentions, comments, and notifications. A record-presence feature could warn users when colleagues are editing the same opportunity.
The platform could also introduce data residency options, dedicated tenant deployments, and regional processing for enterprise customers. Reporting might evolve into a full analytics platform with scheduled dashboards, forecasting, and a semantic model.
These improvements should be introduced according to measured customer needs. The initial architecture should remain simple enough to operate while leaving clear boundaries for future capabilities.
A CRM platform is more than a database of contacts. It combines transactional records, activity timelines, flexible schemas, detailed permissions, workflow automation, search, reporting, and third-party integrations.
Web applications, mobile applications, administrative portals, and integrations access the system through an API Gateway. Behind the gateway, specialised services own records, activities, permissions, workflows, search, reporting, and integrations.
The platform uses synchronous communication when an immediate answer is required and asynchronous events for indexing, automation, auditing, and analytics. The transactional outbox pattern ensures that record updates and their events remain consistent.
Multi-tenancy is the foundation of the design. Every record, query, cache entry, background job, and event must carry tenant context. Permission checks provide an additional layer of protection within each organisation.
The most important design challenge is balancing flexibility with predictable performance and strong security. Customers expect to customise the platform, but the underlying system must remain scalable, searchable, and safe.
A strong CRM design recognises these competing requirements and creates clear boundaries between the transactional source of truth and the specialised systems that support search, automation, integration, and analysis.