DEV Community: Naresh Chandra Lohani

How to Build Generative AI Development Services with a Production-Ready RAG Architecture

Naresh Chandra Lohani — Mon, 07 Sep 2026 10:41:38 +0000

A common failure in production LLM applications is not the model itself. It is the application sending incomplete, stale, or irrelevant context to the model. This appears when a chatbot must answer questions from private documents, customer records, product catalogs, or frequently changing operational data.

Generative AI Development Services address this problem by combining foundation models with application-specific retrieval, APIs, business rules, and observability. Instead of asking an LLM to answer from its training data alone, a RAG architecture retrieves relevant application data before inference.

For teams evaluating custom generative AI solutions, the important engineering question is not simply which model to use. It is how to construct the complete inference path so that retrieval quality, latency, security, and failure handling can be measured independently.

Context and Setup

The recommended architecture separates application requests, retrieval, model inference, and operational data.

A typical request flow looks like this:

Client
  |
  v
API Gateway / Node.js
  |
  +----> Authentication + rate limiting
  |
  v
Query processing
  |
  +----> Vector / hybrid search
  |           |
  |           v
  |       Relevant context
  |
  v
LLM inference
  |
  v
Response validation
  |
  v
Client

For a production deployment, Node.js or Python can handle orchestration, Docker can package services consistently, and AWS can provide the networking, storage, compute, monitoring, and model infrastructure.

This architecture also addresses an important industry problem: AI adoption is high, but confidence in AI output remains limited. Stack Overflow's 2025 Developer Survey reported that 84% of developers were using or planning to use AI tools, while only 29% trusted AI output to be accurate.

That trust gap is an engineering problem. Retrieval, validation, logging, and deterministic application logic need to surround probabilistic model output.

Designing Generative AI Development Services Around RAG

Step 1: Separate Retrieval From Generation

The first step is to make knowledge retrieval an independent service.

Do not put every document into a massive prompt. Instead:

Split source documents into meaningful chunks.
Generate embeddings for each chunk.
Store embeddings with document metadata.
Convert the user's query into an embedding.
Retrieve the most relevant chunks.
Pass only the selected context to the LLM.

AWS recommends RAG when foundation models need to answer questions using authoritative external information such as proprietary documents and internal knowledge bases.

This separation also makes debugging easier. If the answer is wrong, engineers can determine whether the problem originated in retrieval or generation.

Step 2: Build a Controlled Inference Pipeline

The second step is to control exactly what reaches the model.

A simplified Node.js service might look like this:

async function answerQuestion(question) {
  // Why: retrieve only application-approved context before inference.
  const documents = await vectorStore.search(question, { topK: 5 });

  // Why: prevents the prompt from growing without a predictable token budget.
  const context = documents.map(doc => doc.text).join("\n");

  const prompt = `
    Answer using only the supplied context.
    If the context is insufficient, say that the information is unavailable.

    Context:
    ${context}

    Question:
    ${question}
  `;

  // Why: keeping model invocation behind one service simplifies observability.
  return await llm.generate(prompt);
}

The important part is not the syntax. It is the boundary around the LLM.

The service should record retrieval latency, number of retrieved documents, token usage, model latency, errors, and validation failures. AWS's current guidance similarly recommends tracking embedding, search, and reranking latency separately instead of treating retrieval as one opaque operation.

For high-volume systems, caching can also reduce repeated retrieval and generation work. AWS documents architectures where Amazon MemoryDB provides single-digit millisecond query times for semantic search, with published configurations reaching up to 33,000 queries per second at 95% to 99% recall.

Those figures are architecture-specific benchmarks, not a universal promise for every RAG implementation.

Step 3: Choose Retrieval Based on Query Behavior

The third step is selecting the retrieval strategy based on the data and query patterns.

A basic vector search is often sufficient for semantic questions. Hybrid search becomes useful when users mix natural language with exact identifiers such as SKUs, ticket numbers, account IDs, or product codes.

The main trade-offs are:

Vector search: simpler semantic matching, but exact identifiers may be weaker.
Keyword search: excellent for exact terms, but weaker for conceptual similarity.
Hybrid retrieval: combines both signals but introduces additional infrastructure and tuning.
Reranking: can improve relevance after retrieval, but adds inference latency.

The goal should be measured relevance, not maximum architectural complexity. AWS's RAG guidance recommends tuning chunking and retrieval against actual query behavior and monitoring each retrieval stage independently.

Real-World Application

In one of our Generative AI Development Services projects at Oodles, we built a financial data chatbot designed to retrieve structured and real-time financial information. The system used React/Next.js on the frontend and FastAPI/Node.js on the backend, with separate agents for Supabase data and real-time financial APIs.

The architecture classified incoming questions, routed them to the appropriate data source, generated structured responses, and included error handling and user feedback. The implementation also prioritized real-time data integration and low-delay responses rather than relying exclusively on static model knowledge.

Another Oodles implementation demonstrates the same principle from a different angle. An e-commerce customer-support solution combined Python, Node.js, NLP, ML, React.js, and AWS, with multilingual support spanning 20+ languages and deployment across web, mobile, and voice interfaces.

For additional engineering examples and AI implementation work, visit Oodles.

Key Takeaways

Treat retrieval as a first-class service. Poor context can produce incorrect answers even when the underlying model is capable.
Measure the entire inference path. Track retrieval, reranking, model, validation, and network latency separately.
Keep context bounded. More retrieved text does not automatically mean better answers.
Use hybrid retrieval when exact identifiers matter. Vector similarity alone may not handle operational queries correctly.
Design for verification. Logs, source references, validation rules, and fallback responses are essential for production AI systems.

Conclusion

Production GenAI is primarily an architecture problem, not a prompt-writing exercise. A successful implementation connects application data, retrieval systems, model inference, security controls, and observability into one measurable pipeline.

The strongest Generative AI Development Services implementations therefore start with a clear data flow, establish measurable retrieval and latency budgets, and introduce model capabilities only where they solve a defined application problem.

Have a RAG, LLM, AI agent, or enterprise AI architecture that needs a technical review? Share your architecture or implementation challenge in the comments, or discuss your requirements directly through Generative AI Development Services.

FAQ

1. What are Generative AI Development Services?

Generative AI Development Services involve designing and integrating applications powered by foundation models such as LLMs and multimodal models. They can include RAG pipelines, AI agents, model integration, prompt orchestration, custom model workflows, APIs, cloud deployment, security, evaluation, and production monitoring.

2. When should I use RAG instead of fine-tuning?

Use RAG when the model needs current, private, or frequently changing information. Fine-tuning is more appropriate when you need to change model behavior, style, or task specialization. RAG changes the information supplied at inference time without retraining the foundation model.

3. How do I reduce latency in a RAG application?

Measure retrieval, embedding, reranking, model inference, and network latency independently. Then optimize the slowest stage. Techniques include smaller retrieval sets, caching, efficient vector indexes, streaming responses, query routing, and avoiding unnecessary reranking or model calls.

4. Are Generative AI Development Services suitable for enterprise applications?

Yes. Generative AI Development Services can support enterprise applications when the architecture includes access controls, private data boundaries, audit logging, evaluation, monitoring, rate limiting, and deterministic business rules around model output. AWS also documents RAG architectures designed for proprietary enterprise data.

5. How can I make LLM responses more reliable?

Reliability improves when the application controls context retrieval, validates model output, records source documents, limits unsupported claims, and provides a fallback when evidence is insufficient. Treat the LLM as one component inside a verified software pipeline rather than as the application's source of truth.

How to Build Inventory Management Services with Odoo and PostgreSQL

Naresh Chandra Lohani — Fri, 04 Sep 2026 07:28:13 +0000

A stock reservation can fail in a surprisingly simple way: two checkout requests read available_qty = 1, both approve the order, and the warehouse later discovers that only one unit exists. This happens when inventory writes are treated like ordinary CRUD operations instead of concurrency-sensitive state transitions. Inventory Management Services need transactional stock updates, idempotent APIs, warehouse-aware data models, and an audit trail for every movement. In this architecture deep dive, we will design that core around Odoo, Python, and PostgreSQL, with patterns applicable to custom ERP and WMS implementations. If you are evaluating inventory and warehouse management solutions, the key architectural question is not only how stock is displayed, but how stock remains correct under concurrent writes.

Context and Setup

The system manages products, warehouses, bins, stock movements, reservations, purchase receipts, sales orders, returns, and adjustments. A typical request path looks like:

Client → API/ERP Layer → Inventory Service → PostgreSQL → Event/Integration Layer

The important design decision is to treat stock movement as the source of truth, rather than allowing multiple application modules to modify a quantity independently.

For example, an SKU can have:

on_hand
reserved
available
incoming
warehouse_id
version

The application can derive:

available = on_hand - reserved

This prevents sales, purchasing, and warehouse modules from maintaining competing definitions of stock.

Database performance also depends heavily on connection management. AWS documents an Aurora PostgreSQL test where reusing connections processed 9,042 transactions in 60 seconds versus 495 when connections were repeatedly established, an approximately 18x difference in that specific test environment.

That is why an inventory platform should use connection pooling rather than creating a database connection for every API request.

Designing Inventory Management Services for Concurrent Stock Updates

Step 1: Model stock around warehouse and SKU boundaries

The first step is separating product identity from physical stock.

A useful relational model is:

CREATE TABLE inventory_balance (
    sku_id BIGINT NOT NULL,
    warehouse_id BIGINT NOT NULL,
    on_hand INTEGER NOT NULL DEFAULT 0,
    reserved INTEGER NOT NULL DEFAULT 0,
    version INTEGER NOT NULL DEFAULT 1,
    PRIMARY KEY (sku_id, warehouse_id) -- Prevents duplicate warehouse balances
);

The composite key matters because SKU-100 may have 50 units in Warehouse A and 20 in Warehouse B. A global quantity cannot correctly represent allocation decisions.

Keep a separate movement ledger for receipts, picks, transfers, returns, and adjustments. The balance becomes the operational read model, while the movement ledger provides traceability.

Step 2: Make reservation atomic

The most dangerous operation is usually reservation. A read followed by a separate update creates a race condition.

PostgreSQL supports SELECT ... FOR UPDATE, which locks selected rows against concurrent updates until the transaction ends.

A Python implementation can therefore make the reservation decision inside one transaction:

def reserve_stock(conn, sku_id, warehouse_id, quantity):
    with conn.transaction():
        with conn.cursor() as cur:
            cur.execute("""
                SELECT on_hand, reserved
                FROM inventory_balance
                WHERE sku_id = %s AND warehouse_id = %s
                FOR UPDATE
            """, (sku_id, warehouse_id))  # Why: serializes competing reservations

            row = cur.fetchone()

            if not row:
                raise ValueError("Inventory record not found")

            on_hand, reserved = row

            if on_hand - reserved < quantity:
                raise ValueError("Insufficient available stock")

            cur.execute("""
                UPDATE inventory_balance
                SET reserved = reserved + %s,
                    version = version + 1
                WHERE sku_id = %s AND warehouse_id = %s
            """, (quantity, sku_id, warehouse_id))  # Why: update occurs under the same lock

The important part is not the Python syntax. The stock check and stock mutation happen under the same database transaction.

For workloads using DynamoDB instead of PostgreSQL, the equivalent pattern is a conditional write. AWS specifically recommends conditional writes for concurrent updates because the condition is evaluated as part of the write operation.

Step 3: Separate synchronous consistency from asynchronous integration

Not every inventory operation belongs in the same transaction.

The reservation itself should remain synchronous because the caller needs an authoritative answer: reserved or rejected.

Notifications, analytics, search indexing, ERP synchronization, and external marketplace updates can be asynchronous.

A practical sequence is:

Lock the inventory balance.
Validate available quantity.
Update the reservation.
Insert an inventory movement.
Commit the transaction.
Publish an event using an outbox pattern.
Process external integrations asynchronously.
Retry failed consumers using an idempotency key.

This approach is preferable to placing external API calls inside the database transaction. External calls can be slow or unavailable, unnecessarily extending lock duration.

For queue-like workloads, PostgreSQL also provides SKIP LOCKED, which can allow multiple consumers to avoid waiting on already-locked rows. PostgreSQL notes that this is appropriate for queue-style processing rather than general-purpose consistent reads.

Real-World Application

In one of our inventory-focused projects at Oodles, My Mandi required an inventory management ERP and mobile marketplace supporting its B2B2C operating model. Oodles implemented the inventory ERP with Odoo, Python, Flutter, and DevOps components, connecting inventory workflows with the marketplace experience. The project supported a membership base of more than 200 on one platform and enabled users to book orders while providing improved reporting visibility.

Another relevant Oodles implementation, Ecom Express, involved Odoo customization across logistics, supply chain, inventory and warehouse operations, storage management, and order fulfillment. Oodles reports a 35% improvement in operational efficiency and a 20% reduction in delivery times for the implementation.

These projects illustrate why Inventory Management Services often need to extend beyond a stock table. The architecture has to connect inventory state with order processing, warehouse execution, procurement, logistics, and reporting.

For more examples of ERP and engineering implementations, visit Oodles.

Performance Considerations

Performance should be measured against the actual workload instead of an arbitrary requests-per-second target.

AWS has demonstrated DynamoDB workloads exceeding 1.1 million requests per second in a benchmark involving distributed reads and writes. That result is a capacity demonstration, not a promise for every inventory application, because schema, item size, access patterns, hot keys, and infrastructure configuration materially affect throughput.

For an inventory service, measure:

Reservation latency at p50, p95, and p99
Database lock wait time
Transaction rollback rate
Stock conflict rate
Queue processing latency
API throughput by warehouse
Integration retry volume

These measurements expose the real bottleneck. A service handling 500 requests per second with correct transactional behavior can be more useful than one handling thousands of requests while occasionally overselling stock.

Conclusion / Key Takeaways

Model inventory by SKU and warehouse, not as one global quantity.
Keep reservation validation and mutation inside the same transaction.
Use PostgreSQL row locks or DynamoDB conditional writes for concurrent stock changes.
Keep external integrations outside the critical transaction path and use an outbox or event-driven workflow.
Benchmark connection pooling, lock contention, reservation latency, and queue throughput under realistic concurrency.

Building or modernizing an inventory platform? Share your architecture, concurrency requirements, warehouse model, or current bottleneck in the comments. We can discuss database locking, event-driven inventory, ERP integration, and warehouse workflows from an implementation perspective.

For a technical discussion with Oodles, contact us about Inventory Management Services.

FAQ

1. What are Inventory Management Services?

Inventory Management Services are software engineering and implementation capabilities for tracking, reserving, moving, replenishing, and auditing stock across products and warehouse locations. They can include ERP/WMS configuration, custom APIs, barcode workflows, integrations, reporting, forecasting, and inventory synchronization.

2. How do you prevent overselling inventory?

Prevent overselling by performing the availability check and reservation update atomically. PostgreSQL applications can use row-level FOR UPDATE locks, while DynamoDB applications can use conditional writes. Both approaches ensure concurrent requests cannot independently approve the same remaining inventory.

3. Should inventory quantity be stored or calculated?

Store an operational balance for fast reads, but maintain an immutable movement ledger for traceability. The balance can represent current on_hand and reserved quantities, while receipts, picks, transfers, returns, and adjustments provide the audit history required to reconstruct inventory changes.

4. When should inventory processing become asynchronous?

Make operations asynchronous when they do not determine the immediate stock decision. Analytics, notifications, search indexing, marketplace synchronization, and reporting are good candidates. Reservation and allocation should normally remain synchronous because the caller requires an authoritative inventory decision before confirming the order.

5. Can Inventory Management Services support multiple warehouses?

Yes. A multi-warehouse design should scope inventory balances, reservations, movements, and allocation rules by warehouse or fulfillment location. This enables the system to answer not only whether an SKU exists, but where it exists, how much is available, and which location should fulfill a particular order.

How ERP Consulting Services Improve ERP Architecture for Node.js Systems

Naresh Chandra Lohani — Thu, 03 Sep 2026 05:20:47 +0000

An ERP integration can fail long before production if business rules, transaction boundaries, and data ownership are poorly defined. A common example is an order service that writes to inventory, accounting, fulfillment, and customer records through separate APIs. Under concurrency, partial failures can leave stock and financial records inconsistent.

This is where ERP Consulting Services becomes an engineering problem rather than simply a software-selection exercise. The architecture needs explicit domain boundaries, idempotent workflows, reliable integration patterns, and observable failure handling. For organizations building or modernizing these systems, custom ERP solutions can provide the foundation for mapping operational requirements to an implementable technical architecture.

Context and Setup

The recommended architecture separates the ERP core from external applications and integration workloads.

A typical Node.js implementation can use:

Node.js for APIs and workflow services
PostgreSQL for transactional ERP data
Redis for short-lived caching and distributed coordination
Docker for repeatable deployments
AWS for compute, managed databases, queues, storage, and observability
Message queues for asynchronous integrations

The important design principle is that the ERP database should not become a shared integration database. Each business capability should have a clear owner, while external systems communicate through APIs or events.

There is a practical reason to take this seriously. ERP Research's September 2026 analysis of 1,948 published ERP case studies found a median disclosed implementation duration of six months, with projects in the middle 50% ranging from three to nine months. The researchers also warn that published implementations are success-biased because unsuccessful projects are less likely to become public case studies.

That makes architecture decisions during discovery especially important. Reworking data models or integration boundaries after deployment is substantially harder than establishing them before implementation.

Designing ERP Consulting Services Around Transaction Integrity

ERP Consulting Services should start with transaction ownership, not screens or modules. Before implementing workflows, identify which service owns each state transition and which operations must be atomic.

Step 1: Define the Business Transaction Boundary

Consider an order workflow:

Validate the customer and order.
Reserve inventory.
Create the financial transaction.
Initiate fulfillment.
Publish the order status event.

Not every operation should run inside one database transaction. Inventory reservation and financial posting may belong to different bounded contexts.

A better pattern is to commit the local transaction first and publish an event using the outbox pattern.

async function createOrder(order) {
  return db.transaction(async (tx) => {
    const saved = await tx.orders.insert(order);

    // Why: the event is committed with the order, preventing lost messages.
    await tx.outbox.insert({
      type: "ORDER_CREATED",
      aggregateId: saved.id,
      payload: JSON.stringify(saved)
    });

    return saved;
  });
}

A background worker then reads the outbox and publishes the event to the integration queue.

This approach avoids a distributed transaction between PostgreSQL and a message broker. It also gives engineers a durable record of events that still need processing.

Step 2: Make ERP Integrations Idempotent

Idempotency prevents duplicate business operations when integrations retry. ERP systems frequently communicate with payment providers, warehouses, CRM platforms, tax services, and shipping systems. Network failures can cause the same request to be delivered more than once.

A simple Node.js API can use an idempotency key:

app.post("/orders", async (req, res) => {
  const key = req.header("Idempotency-Key");

  // Why: retries must return the original result instead of creating another order.
  const existing = await redis.get(`order:${key}`);

  if (existing) {
    return res.status(200).json(JSON.parse(existing));
  }

  const order = await createOrder(req.body);

  // Why: a short-lived cache blocks duplicate submissions during retry windows.
  await redis.set(`order:${key}`, JSON.stringify(order), { EX: 3600 });

  res.status(201).json(order);
});

Redis alone should not be treated as the final source of truth. For critical operations, enforce uniqueness at the PostgreSQL level as well.

This is one area where ERP Consulting Services can directly influence backend reliability because the consultant's job is to translate business rules into enforceable technical constraints.

Step 3: Choose Events Over Synchronous Chains Where Appropriate

Asynchronous events are preferable when downstream systems do not need to respond before the transaction completes.

For example:

Order Created → Inventory Reserved → Invoice Generated → Fulfillment Started

A synchronous chain creates a dependency path where one slow or unavailable service can delay the entire operation. Event-driven processing isolates failures and allows individual consumers to retry.

The trade-off is eventual consistency. A dashboard may briefly show an order as "processing" while the accounting service catches up.

For financial posting, stock reservation, and compliance workflows, engineers should explicitly define acceptable consistency windows rather than assuming every ERP operation requires immediate global consistency.

Real-World Application

In one of our ERP implementations at Oodles, Genie was designed as a full-scale ERP platform spanning production, inventory, sales, HR, finance, and marketing. The architecture included production planning, compliance workflows, QR-based inventory tracking, real-time stock updates, sales workflows, financial operations, and dashboards. Oodles also implemented Gantt scheduling, task dependencies, automated compliance logs, and warehouse mapping.

The implementation demonstrates why ERP architecture has to model operational dependencies rather than simply expose CRUD endpoints. Inventory movement, production planning, compliance, sales, and finance each have different consistency and audit requirements.

Oodles also documents ERP work involving Odoo, Python, PostgreSQL, SQL-based reporting, migration workflows, and system optimization, showing how ERP Consulting Services can span architecture, integration, data migration, and operational support rather than being limited to initial implementation.

For additional engineering context, Oodles documents its ERP implementation, integration, customization, and cloud deployment capabilities.

Conclusion / Key Takeaways

Define ownership first: Every ERP entity and state transition needs a clearly identified system of record.
Use the outbox pattern: It reduces the risk of committing database state while losing the corresponding integration event.
Design for retries: Idempotency keys and database uniqueness constraints should protect critical ERP operations.
Separate synchronous and asynchronous work: User-facing transactions should not depend unnecessarily on slow downstream integrations.
Treat consistency as a business decision: Finance, inventory, and compliance workflows may require different consistency guarantees.

Have a specific ERP integration, migration, data-modeling problem, or event-driven architecture you are evaluating? Share the technical constraints in the comments, or discuss your architecture requirements with the Oodles engineering team through ERP Consulting Services.

FAQ

What are ERP Consulting Services?

ERP Consulting Services help organizations analyze business processes, select or customize ERP platforms, design integrations, migrate data, configure workflows, and establish technical architecture. For engineering teams, the work can also include APIs, event processing, database design, security, deployment, observability, and post-launch optimization.

When should an ERP use an event-driven architecture?

An ERP should consider event-driven architecture when multiple systems need to react to business events independently. Orders, inventory changes, payments, fulfillment updates, and customer events are common examples. Events reduce synchronous coupling, but teams must explicitly design retry, ordering, duplication, and eventual-consistency behavior.

Why is idempotency important in ERP integrations?

Idempotency prevents retries from creating duplicate business operations. If a network timeout occurs after an order is created, the client may submit the same request again. An idempotency key combined with a database uniqueness constraint allows the system to return the original result instead of creating another transaction.

How do ERP Consulting Services reduce implementation risk?

ERP Consulting Services reduce implementation risk by identifying process dependencies, data ownership, integration requirements, security constraints, and non-functional requirements before development. A technical architecture can then be validated against real workflows instead of discovering critical constraints after modules and integrations are already deployed.

Should ERP data always be strongly consistent?

No. Strong consistency is appropriate for operations such as financial posting or inventory reservation where incorrect state can have direct business consequences. Reporting, search indexes, notifications, and some dashboards can tolerate eventual consistency. The architecture should define consistency requirements per workflow rather than applying one model everywhere.

How to Design Odoo Implementation Services for Production-Grade ERP Performance

Naresh Chandra Lohani — Wed, 02 Sep 2026 06:15:52 +0000

A common Odoo production problem starts innocently: a custom module works correctly with 20 records, but becomes slow when users process thousands of records concurrently. The root cause is rarely Odoo alone. It is usually a combination of ORM usage, PostgreSQL queries, worker sizing, scheduled jobs, custom business logic, and deployment configuration.

This is where Odoo Implementation Services need to be treated as an engineering discipline rather than an installation task. The architecture should be designed around actual transaction patterns, database volume, integrations, and concurrency requirements.

For teams planning a production deployment, Odoo implementation services should therefore include profiling, database design, deployment configuration, testing, and operational monitoring from the beginning.

Context and Setup

The right architecture starts with understanding how Odoo processes requests. A typical production deployment contains an Odoo application layer, PostgreSQL, a reverse proxy, background workers, scheduled actions, filestore storage, and external integrations.

Odoo's current deployment documentation provides a useful sizing reference: its rule of thumb is (# CPU × 2) + 1 workers, while one worker is estimated at approximately six concurrent users. Odoo also notes that worker count alone does not solve slow application logic.

Before implementation, establish these prerequisites:

Define expected concurrent users and peak transaction volume.
Identify modules requiring customization.
Map external APIs and synchronization frequency.
Estimate PostgreSQL database and filestore growth.
Separate synchronous user operations from asynchronous jobs.
Establish response-time and error-rate baselines.

This prevents infrastructure sizing from becoming a guess made after production deployment.

Odoo Implementation Services: A Performance-First Architecture

A production implementation should optimize the application, database, and deployment layers together. Changing only server resources can hide inefficient Python or SQL code rather than fixing it.

Step 1: Profile the Transaction Before Optimising It

The first step is to identify where time is actually being spent.

Odoo provides an integrated profiler that can record SQL queries and execution traces. Its documentation specifically recommends profiling to identify which part of a program is responsible for performance problems.

A practical workflow is:

Reproduce the slow operation with realistic data.
Enable SQL and trace profiling.
Identify repeated queries and expensive methods.
Check whether the ORM is performing unnecessary record-by-record operations.
Compare database time with Python execution time.
Repeat the measurement after every meaningful change.

For example, avoid designing custom logic that repeatedly searches the database inside a loop:

# Why: one batched search avoids issuing a query for every record.
partners = self.env["res.partner"].search([
    ("email", "in", emails)
])

partner_by_email = {
    partner.email: partner
    for partner in partners
}

for email in emails:
    partner = partner_by_email.get(email)
    # Continue processing with the already-loaded record.

The important principle is not simply "write faster Python." It is to reduce unnecessary database round trips.

Step 2: Make PostgreSQL and ORM Work Together

The second step is database-aware module development.

Odoo's performance guidance recommends batch operations, reducing algorithmic complexity, and using indexes where appropriate. It also warns that excessive indexes consume storage and can increase the cost of insert and update operations.

For a custom model, an index can be appropriate when a field is frequently used for filtering:

class Shipment(models.Model):
    _name = "logistics.shipment"

    # Why: frequent status filtering benefits from a database index.
    status = fields.Selection(
        [
            ("draft", "Draft"),
            ("ready", "Ready"),
            ("shipped", "Shipped"),
        ],
        index=True,
    )

The trade-off matters. Indexing every searchable field can increase write overhead and database size. The correct approach is to inspect actual query patterns and add indexes where they support high-value access paths.

For large datasets, also review:

ORM domains
computed fields
stored computed fields
relational field access
PostgreSQL execution plans
batch create/write operations
scheduled jobs processing large recordsets

Step 3: Configure Workers Around Real Concurrency

The third step is production process configuration.

Odoo's multiprocessing server is designed for production deployments, while the multi-threaded mode is primarily intended for development and demonstrations. Odoo's documentation also provides worker and memory sizing guidance based on CPU capacity and workload.

A simplified production configuration might look like:

[options]

# Why: enables multiprocessing for production HTTP workloads.
workers = 8

# Why: prevents an individual worker from consuming uncontrolled memory.
limit_memory_soft = 629145600

# Why: provides a hard safety boundary for worker memory usage.
limit_memory_hard = 1677721600

# Why: controls the maximum number of HTTP requests per worker lifecycle.
limit_request = 8192

# Why: reserves capacity for scheduled background processing.
max_cron_threads = 1

These values are examples, not universal recommendations. Worker count must be validated against CPU, memory, database capacity, transaction characteristics, and concurrency.

Increasing workers can actually expose database contention if PostgreSQL cannot process the additional concurrent workload. That is why worker tuning should follow application and SQL profiling rather than precede it.

Real-World Application

In one of our Odoo Implementation Services projects at Oodles, Paper & Pack required a production-oriented Odoo Community v17 server setup. The challenge was not simply installing Odoo. The environment needed PostgreSQL configuration, secure SSH access, Python dependencies, source-code management, configuration handling, and a repeatable deployment process.

Oodles created a terminal-based setup workflow covering server hardening with Fail2ban, PostgreSQL configuration, Odoo source deployment, Python dependency installation, and environment configuration.

Another implementation for Green Energy Africa involved Odoo modules for accounting, inventory, POS, attendance, and WhatsApp integration, with Python scripting and SQL used for customization and integration. The rollout also included five days of department-specific training, providing a concrete implementation milestone rather than treating deployment as the end of the project.

The engineering lesson is straightforward: production readiness includes infrastructure, application behavior, integrations, data, and user adoption.

You can explore more implementation work from Oodles.

Key Takeaways

Profile before changing infrastructure. Slow SQL or inefficient ORM logic can remain slow even after adding workers.
Batch database operations. Reducing query count is often more valuable than micro-optimising Python.
Treat indexes as workload-specific. They improve reads but add write and storage costs.
Size workers against concurrency and memory. Odoo's documented worker guidance is a starting point, not a substitute for load testing.
Make deployment repeatable. Versioned configuration, dependency management, security controls, and documented setup reduce operational variance.

If you are designing a custom Odoo architecture, migrating an existing ERP, or investigating production performance problems, technical discussion is often the fastest way to identify the right implementation boundary.

Share your architecture, workload pattern, or bottleneck in the comments, or discuss your requirements with the Oodles engineering team through Odoo Implementation Services.

FAQ

1. What are Odoo Implementation Services?

Odoo Implementation Services cover the technical and functional work required to deploy Odoo for a specific organization. This can include requirements analysis, module configuration, custom development, integrations, data migration, infrastructure setup, testing, deployment, training, and post-production support.

2. How many Odoo workers should I configure?

Odoo's documentation gives CPU cores × 2 + 1 as a worker rule of thumb and estimates roughly six concurrent users per worker. Actual sizing depends on transaction complexity, memory availability, database workload, scheduled jobs, and peak concurrency, so load testing remains necessary.

3. How can I diagnose a slow Odoo module?

Start with reproducible measurements rather than changing server resources. Use Odoo's integrated profiler to inspect SQL queries and execution traces, identify repeated queries, examine expensive methods, and then retest after code or database changes.

4. Should every Odoo search field have a database index?

No. An index should be added when query patterns justify it. Odoo documentation notes that indexes can improve searches, but they consume storage and can negatively affect insert and update performance. Analyze real queries before adding indexes to custom models.

5. When should I use Odoo Implementation Services instead of configuring Odoo internally?

Use Odoo Implementation Services when the deployment involves substantial customization, integrations, migration, infrastructure decisions, complex workflows, or performance requirements. External implementation expertise can help establish architecture, automate deployment, validate workloads, and reduce risks before production.

How to Build Faster CRM Platforms with CRM Software Development Services

Naresh Chandra Lohani — Tue, 01 Sep 2026 06:15:13 +0000

A CRM API can become slow long before the application reaches millions of users. A common failure pattern is a dashboard that executes several joins, loads an entire activity history, calls external services synchronously, and recalculates pipeline metrics on every request. The result is rising database load and inconsistent API latency during peak traffic.

This is where CRM Software Development Services require more than feature development. The architecture needs deliberate decisions around data modeling, caching, asynchronous processing, API boundaries, and observability. For teams building or modernizing a CRM, custom CRM application development can provide the engineering foundation for these requirements.

This article explains a practical architecture using Node.js, PostgreSQL, Redis, Docker, and AWS, with an emphasis on measurable performance rather than adding infrastructure without evidence.

Context and Setup

The recommended architecture separates transactional CRM data from read-heavy operations such as dashboards, search, notifications, and analytics.

A typical request path looks like:

Web / Mobile Client
        |
    API Gateway
        |
   Node.js Services
     /    |     \
PostgreSQL Redis  Queue
     |             |
 CRM Data      Worker Services

PostgreSQL remains the system of record for leads, contacts, accounts, deals, activities, and permissions. Redis handles frequently requested, reconstructable data. A queue processes operations that do not need to block the user's HTTP request.

This design follows AWS guidance to select data stores according to access patterns and workload requirements rather than applying one database strategy everywhere. AWS also recommends caching read-heavy workloads and monitoring cache effectiveness.

There is also a useful industry signal for the selected stack. The 2025 Stack Overflow Developer Survey reported a 7 percentage point year-over-year increase in Python usage, while Node.js remains a widely used web technology among developers.

Designing CRM Software Development Services for API Performance

Step 1: Model the Read Path Before Optimizing It

The first step is identifying what the CRM actually reads.

A dashboard request might require:

Open opportunities by stage.
Recent customer activities.
Salesperson performance.
Upcoming follow-ups.
Monthly revenue totals.

Putting all five calculations into one SQL query creates a difficult optimization problem. Instead, separate transactional queries from aggregated data.

For example, frequently accessed CRM entities can use indexes around actual query patterns:

CREATE INDEX idx_deals_owner_stage
ON deals(owner_id, stage);

CREATE INDEX idx_activities_contact_created
ON activities(contact_id, created_at DESC);

The reason is simple: indexes reduce unnecessary database scanning for common filtering and ordering operations. AWS specifically recommends query optimization strategies such as indexing and partitioning when they match workload access patterns.

Do not index every column. Each additional index increases storage requirements and can add work to inserts and updates.

Step 2: Add Cache-Aside for High-Read CRM Data

CRM Software Development Services should treat caching as a workload decision, not a default architecture component.

A useful candidate is a CRM dashboard configuration or frequently requested customer profile. Redis can store the serialized result with a short TTL.

A Node.js implementation can use a cache-aside pattern:

async function getCustomer(customerId) {
  const key = `customer:${customerId}`;

  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached); // Why: avoids a database read on cache hits

  const customer = await db.customer.findUnique({
    where: { id: customerId }
  });

  await redis.set(
    key,
    JSON.stringify(customer),
    { EX: 300 } // Why: limits stale CRM data to five minutes
  );

  return customer;
}

The important part is invalidation. When the customer changes, the application should remove or update the associated cache entry.

AWS recommends monitoring cache hit rate and notes that caching can reduce read latency, increase read throughput, and reduce pressure on primary data stores.

For highly dynamic records, caching may introduce stale reads. In those cases, use shorter TTLs or avoid caching the record entirely.

Step 3: Move Non-Critical Operations to Workers

A CRM should not make users wait for every downstream operation.

Consider a lead creation endpoint that also needs to:

Save the lead.
Send an email.
Notify a sales representative.
Create an analytics event.
Synchronize an external CRM.
Generate an audit record.

Only the first operation necessarily belongs in the critical request path.

A queue-based design can return after the transactional operation succeeds:

await db.lead.create({ data: lead }); // Why: transactionally persist the CRM record

await queue.publish({
  type: "LEAD_CREATED",
  leadId: lead.id
}); // Why: downstream work can execute independently

return res.status(201).json({ id: lead.id });

Workers can then process email, synchronization, analytics, and notifications independently.

The trade-off is eventual consistency. A sales representative may see the lead immediately while an external integration updates a few seconds later. That is usually acceptable for background synchronization, but not for operations requiring an immediate response.

Real-World Application

In one of our CRM-related projects at Oodles, Once Upon A Wish CRM involved building a customized travel management module within Odoo Community v18, using Python and PostgreSQL. The system included itinerary management, centralized booking, expense tracking, and client communication capabilities. The reported project impact was a 30% reduction in manual workload and a 40% improvement in operational efficiency.

The engineering lesson is important: CRM performance is not limited to API milliseconds. Workflow automation can remove repetitive operations from the system's critical business path, which changes the total operational cost of a CRM.

For teams evaluating architecture, Oodles documents CRM implementations across technologies including Python, Node.js, PostgreSQL, MongoDB, and REST APIs.

Key Takeaways

Index according to queries: Design database indexes from measured access patterns rather than adding indexes indiscriminately.
Cache selectively: Use Redis for frequently requested, reconstructable data where stale reads are acceptable.
Keep requests short: Move email, analytics, notifications, and third-party synchronization into background workers.
Measure before tuning: Track p95/p99 latency, database query duration, cache hit rate, queue delay, and error rate.
Design for consistency: Explicitly classify operations as strongly consistent or eventually consistent before introducing asynchronous processing.

Have a CRM API that becomes slow under concurrent dashboard traffic, integration load, or reporting queries? Share your architecture, bottleneck, or database pattern in the comments.

If you want to discuss
CRM Software Development Services for a custom CRM, modernization project, or performance-focused architecture, the Oodles engineering team can discuss the technical constraints and possible implementation paths.

FAQ

1. What are CRM Software Development Services?

CRM Software Development Services cover the engineering of custom customer relationship platforms, including CRM data models, APIs, workflows, integrations, dashboards, automation, authentication, reporting, and deployment infrastructure. The architecture can be tailored around an organization's sales processes instead of forcing those processes into a fixed CRM product.

2. Should a CRM use PostgreSQL or MongoDB?

PostgreSQL is often suitable when CRM records require relational integrity, transactions, joins, and structured reporting. MongoDB can fit document-oriented workloads with flexible schemas. The correct choice depends on access patterns, consistency requirements, query complexity, and scale rather than database popularity.

3. When should Redis be added to a CRM?

Redis should be added when profiling shows repeated reads that are expensive or place unnecessary load on the primary database. Suitable candidates include dashboard summaries, configuration data, sessions, and frequently accessed records. Cache invalidation and TTL policies should be defined before production deployment.

4. How can CRM APIs handle high traffic?

High-traffic CRM APIs can use indexed database queries, connection pooling, caching, horizontal application scaling, asynchronous workers, rate limiting, and observability. Load testing should establish baseline throughput and p95/p99 latency before optimization so architectural changes can be evaluated against measurable results.

5. Are CRM Software Development Services suitable for existing CRM platforms?

Yes. CRM Software Development Services can extend or modernize existing CRM platforms through custom modules, API integrations, workflow automation, data migration, performance optimization, and external service integration. A phased approach can preserve existing business processes while individual components are replaced or improved.

How to Build Production-Ready Computer Vision Services with Python, FastAPI, and Docker

Naresh Chandra Lohani — Mon, 31 Aug 2026 06:13:05 +0000

A computer vision model can perform well in a notebook and still fail inside a production API. The common causes are not always model accuracy. Image decoding, repeated model loading, oversized payloads, synchronous inference, CPU contention, and inefficient object storage access can dominate the request path. Computer Vision Services need an application architecture that treats inference as a production workload rather than a standalone ML experiment. In this guide, we will build a practical Python architecture around FastAPI, OpenCV, a YOLO-style detector, Docker, and AWS storage. For teams evaluating custom computer vision development, the key lesson is to design the inference path before optimizing individual model operations.

Context and Setup

The right architecture separates image ingestion, preprocessing, inference, and result delivery. A typical request should look like:

Client → FastAPI → Validation → Image Decode → Preprocessing → Model Inference → Postprocessing → JSON

For asynchronous workloads, the API can instead enqueue the image and return a job identifier:

Client → API → Queue → Worker → Vision Model → Result Store

This distinction matters when processing video frames, bulk images, or large document collections.

AWS documents an important latency consideration for Amazon Rekognition: when processing near-real-time uploads, sending image bytes directly can be faster than first uploading them to Amazon S3. Conversely, if the image already exists in S3, referencing the stored object can be faster than transmitting it again.

For moderation workloads, AWS also reports that machine-learning filtering can reduce the content requiring human review to typically 1% to 5% of total volume.

These figures illustrate a broader engineering principle: the data path surrounding a vision model can materially affect system performance.

Designing Computer Vision Services for Predictable Inference

Step 1: Load the model once

The first rule is simple: never initialize a large vision model for every HTTP request.

Model initialization belongs in application startup or worker initialization. Otherwise, concurrent requests can repeatedly allocate model weights and consume memory before inference even begins.

A FastAPI service can keep the model in process memory:

from fastapi import FastAPI, UploadFile, File
from PIL import Image
from io import BytesIO

app = FastAPI()

# Why: loading once avoids repeated model initialization per request.
model = load_vision_model("model.pt")

@app.post("/detect")
async def detect(file: UploadFile = File(...)):
    image = Image.open(BytesIO(await file.read()))

    # Why: inference uses the already-loaded model.
    result = model.predict(image)

    return {"detections": result}

For production, the actual model loader can initialize YOLO, PyTorch, OpenCV, or another inference engine. The important architectural property is model reuse.

A useful deployment pattern is one model instance per worker process, with worker count chosen according to available CPU or GPU memory. Increasing workers without checking memory consumption can turn a latency optimization into an out-of-memory failure.

Step 2: Control the image preprocessing path

Preprocessing should be explicit and measurable.

A vision endpoint should validate MIME type, maximum payload size, image dimensions, and supported formats before sending data to the model.

Then normalize the image once:

import cv2
import numpy as np

def preprocess(image_bytes: bytes):
    # Why: decode directly into an array for OpenCV operations.
    buffer = np.frombuffer(image_bytes, dtype=np.uint8)
    image = cv2.imdecode(buffer, cv2.IMREAD_COLOR)

    if image is None:
        raise ValueError("Invalid image")

    # Why: bounding memory and compute cost for oversized inputs.
    image = cv2.resize(image, (640, 640))

    return image

The resize strategy should match the model's training and inference configuration. Blindly reducing every image to a fixed resolution can remove small objects that are important to detection accuracy.

Measure preprocessing time separately from inference time:

total_latency = validation + decode + preprocessing + inference + postprocessing

Without those measurements, engineers often optimize the model when the actual bottleneck is image handling.

Step 3: Choose synchronous or asynchronous inference

Use synchronous inference when the response must contain the prediction immediately and individual requests are relatively lightweight. Use asynchronous workers when processing can tolerate delayed results.

A queue-based design is usually better for video analysis, document batches, OCR pipelines, and large image collections because HTTP workers do not remain occupied while GPU or CPU workers process jobs.

The trade-off is operational complexity. A queue requires job state, retries, idempotency, dead-letter handling, and result persistence.

For simple image classification, adding a distributed queue may create more infrastructure than the workload needs. For thousands of independent images, it can prevent API traffic from directly competing with model execution.

Real-World Application

In one of our Computer Vision Services projects at Oodles, the Ceiling Measurement Tool addressed a practical industrial problem: replacing manual ceiling-height measurements with camera-based analysis. The solution used Python and YOLOv8 to detect ceilings, floors, and propellers, followed by an algorithm that converted pixel positions into real-world height measurements. It supported both calibration-assisted and calibration-free workflows.

The important measurable output was not simply a bounding box. The pipeline transformed image coordinates into a physical measurement, allowing the application to return height data in real-world units. That distinction is critical in industrial computer vision, where detection accuracy alone does not define whether the system solves the business problem.

Another Oodles implementation, Ai Rento Soft, used Python-based computer vision to compare vehicle images and provide API-based, real-time damage detection from uploaded images.

The architecture pattern is reusable: isolate model inference behind an API, normalize inputs, return structured predictions, and keep business workflows separate from model-specific code.

You can explore more engineering work from Oodles across computer vision, AI, and application development.

Key Takeaways

Load models once: Model initialization should happen during worker startup, not inside every request.
Measure the complete pipeline: Decode, preprocessing, inference, and postprocessing need separate latency measurements.
Control concurrency: More API workers do not automatically mean faster inference, especially when GPU memory is shared.
Use queues selectively: Async processing is valuable for batch and video workloads but adds operational components.
Optimize the data path: Image transport, storage location, resolution, and serialization can affect latency as much as model execution.

If you are designing an image recognition API, OCR workflow, object detection pipeline, or video analytics system, share your architecture and bottleneck in the comments. The interesting engineering questions are usually around model serving, GPU utilization, preprocessing, and failure handling rather than model selection alone.

For a technical discussion about Computer Vision Services, contact Oodles.

FAQ

What are Computer Vision Services?

Computer Vision Services are production software systems that use image or video data to perform tasks such as object detection, classification, OCR, segmentation, facial analysis, measurement, or visual inspection. They typically combine ML models with APIs, preprocessing, storage, monitoring, and application workflows.

How do I deploy a computer vision model with Python?

Deploy the model behind a Python API such as FastAPI, load model weights during application startup, validate incoming files, preprocess images consistently, execute inference, and return structured JSON results. Docker can package the runtime and dependencies for repeatable deployment.

Should computer vision inference be synchronous or asynchronous?

Synchronous inference is appropriate when users need immediate predictions from relatively small images. Asynchronous processing is better for batch images, long videos, and computationally expensive workflows because queues and workers prevent long-running inference from blocking API request handling.

How can I reduce computer vision API latency?

Reduce unnecessary image transfers, resize inputs according to model requirements, load models once per worker, avoid repeated conversions, measure preprocessing separately from inference, and select worker counts based on CPU or GPU capacity. AWS specifically documents image transport choices that can affect Rekognition latency.

Are Computer Vision Services suitable for real-time applications?

Yes. Computer Vision Services can support real-time inspection, vehicle damage detection, camera analytics, identity workflows, and industrial measurement when the model and surrounding API are engineered for the target latency. The architecture must account for capture rate, preprocessing cost, inference time, hardware, and concurrency.

How to Build Low-Latency RAG Systems with Generative AI Development Services

Naresh Chandra Lohani — Fri, 28 Aug 2026 04:43:59 +0000

A RAG application can return a technically correct answer and still fail in production if users wait several seconds before seeing anything. The delay usually comes from the full request path: query classification, embedding generation, vector search, prompt construction, LLM inference, and response delivery.

This is where Generative AI Development Services need to focus on system architecture, not only model selection. A production RAG pipeline should measure each stage independently and stream output whenever possible.

For teams building enterprise AI assistants, Oodles' Generative AI development services can be applied to architectures where retrieval quality, latency, observability, and model costs have to be considered together.

Context and Setup

The target architecture is a document-grounded assistant serving concurrent users through an API.

A typical request looks like:

Client
  |
API Gateway
  |
FastAPI / Node.js service
  |
Query processing
  |
Vector database
  |
Context builder
  |
LLM
  |
Streaming response

The important point is that LLM latency is only one part of the user-visible delay.

Amazon SageMaker's generative AI benchmarking documentation recommends measuring request latency, time to first token, inter-token latency, and output-token throughput rather than relying on a single average response-time number.

That distinction matters because a response that takes four seconds overall can feel much faster if the first useful token arrives in 500 ms and the remaining output streams progressively.

Stack Overflow's 2025 Developer Survey also reported that 84% of developers were using or planning to use AI tools, while only 29% said they trusted AI output accuracy.

For enterprise RAG, this makes observability and source-grounded responses engineering requirements rather than optional monitoring features.

Generative AI Development Services for Low-Latency RAG

Step 1: Separate Retrieval From Generation

The first design decision is to make retrieval independently measurable.

Do not send every user query directly into an LLM and expect the model to determine everything. Instead:

Normalize the incoming query.
Generate an embedding.
Search the vector database.
Apply metadata or authorization filters.
Select the most relevant chunks.
Construct the final model context.
Send only the required context to the LLM.

This creates clear latency boundaries.

For example, if the total request takes 1.8 seconds, your tracing should tell you whether the time was spent on embedding generation, vector search, prompt construction, model inference, or network transfer.

It also makes optimization safer. A slow vector search should not trigger unnecessary model changes.

Step 2: Stream the Model Response

The second step is to stop treating the LLM response as one large payload.

With FastAPI, a streaming endpoint can begin sending model output while generation continues:

from fastapi import FastAPI
from fastapi.responses import StreamingResponse

app = FastAPI()

async def generate_tokens(prompt: str):
    # Why: stream partial output so users do not wait for the full generation.
    for token in ["RAG", " systems", " need", " measurable", " latency."]:
        yield token

@app.get("/answer")
async def answer(q: str):
    # Why: keep retrieval and generation behind one controlled API boundary.
    return StreamingResponse(
        generate_tokens(q),
        media_type="text/plain"
    )

The production implementation would connect generate_tokens() to the selected model provider's streaming interface.

AWS also provides latency-optimized inference options for supported Amazon Bedrock models, although AWS notes that actual results vary according to prompt length, output size, network conditions, and application architecture.

The engineering lesson is simple: benchmark the complete application path instead of assuming that a faster model automatically creates a faster product.

Step 3: Control Context Size Before Changing Models

The third step is reducing unnecessary tokens.

A common mistake is retrieving ten large chunks when three highly relevant chunks would provide enough evidence.

A practical retrieval pipeline can use:

Metadata filtering before vector similarity.
Top-k retrieval with a conservative initial value.
Optional reranking for ambiguous queries.
Chunk deduplication.
Context-size limits.
Prompt templates that separate instructions from retrieved evidence.

The trade-off is retrieval quality versus latency and token cost.

Increasing top_k may improve recall, but it also increases prompt size and potentially model processing time. Reducing it too aggressively can remove evidence needed for a correct answer.

This is why Generative AI Development Services should treat retrieval parameters as production configuration that can be benchmarked and tuned, rather than hard-coded values.

Real-World Application

In one of our Generative AI Development Services projects at Oodles, we worked on AlmostHuman.ai, an enterprise conversational intelligence platform requiring real-time voice and chat interactions, contextual memory, multilingual processing, and integrations with CRM, ITSM, and workflow systems.

The architecture used multiple specialized agents for dialogue, workflow, knowledge, compliance, translation, and insights. The implementation also incorporated RAG and contextual memory for grounded responses.

A key performance target was low-latency interaction. Oodles reports achieving less than 300 ms interaction latency for its real-time voice and chat processing implementation.

The project demonstrates why latency has to be designed across the entire pipeline. Agent orchestration, retrieval, speech processing, integrations, and response generation all participate in the user-visible experience.

For additional examples of Oodles engineering work across AI systems, RAG applications, and conversational platforms, visit Oodles.

Conclusion: Key Takeaways

Measure stages independently: Track embedding, retrieval, generation, and delivery latency instead of only measuring total API time.
Stream generated output: Time to first token can have a larger effect on perceived responsiveness than total generation time.
Keep retrieval selective: More retrieved context is not automatically better. Evaluate relevance against latency and token consumption.
Use production traces: Capture P50, P90, and P99 latency so occasional slow requests do not disappear inside averages.
Optimize the architecture first: Model selection is only one variable in a RAG system's performance profile.

If you are designing a RAG assistant, agentic workflow, enterprise chatbot, or low-latency AI application, share your architecture or performance bottleneck in the comments. We can discuss practical approaches for retrieval, model orchestration, streaming, and observability.

For a technical discussion with our engineering team, contact Generative AI Development Services.

FAQ

What are Generative AI Development Services?

Generative AI Development Services cover the engineering required to build production AI applications using foundation models, RAG, agents, vector databases, APIs, and supporting infrastructure. The work can include architecture, model integration, retrieval pipelines, evaluation, observability, deployment, and performance optimization.

How can RAG response latency be reduced?

RAG latency can be reduced by limiting retrieved context, applying metadata filters, optimizing vector search, caching repeated operations, using appropriate model inference settings, and streaming generated output. Each stage should be benchmarked independently because total latency is the combined result of multiple network and processing steps.

Should every RAG application use a vector database?

No. A vector database is useful when semantic retrieval across unstructured or high-volume content is required, but simpler applications may work better with relational queries, full-text search, or a hybrid retrieval strategy. The storage and search architecture should match the query patterns and data volume.

What latency metrics should an AI application monitor?

An AI application should monitor end-to-end request latency, time to first token, inter-token latency, output-token throughput, and percentile measurements such as P50, P90, and P99. These metrics distinguish model-generation problems from retrieval, networking, orchestration, or API-layer bottlenecks.

When should a RAG system use reranking?

Reranking is useful when initial vector retrieval returns several plausible documents but relevance varies significantly. A reranker can reorder candidates before they enter the LLM context. The trade-off is additional computation, so it should be introduced only when retrieval-quality measurements show that basic similarity search is insufficient.

How to Design Production-Ready Odoo Implementation Services

Naresh Chandra Lohani — Thu, 27 Aug 2026 10:59:53 +0000

A common ERP failure starts before deployment: business workflows are mapped directly to screens instead of to data, permissions, integrations, and transaction boundaries. The result is an Odoo instance that works in a demo but becomes difficult to operate when orders, inventory movements, accounting entries, and integrations grow.

This is where Odoo Implementation Services need an engineering-first approach. The implementation should define the domain model, module boundaries, PostgreSQL access patterns, integration contracts, security rules, deployment topology, and operational ownership before custom code is added. Oodles approaches Odoo implementation and integration around this combination of configuration, customization, integration, testing, and training.

Context and Setup

A production Odoo architecture typically has four important layers:

Odoo application layer: Standard modules plus controlled custom modules written in Python.
ORM and PostgreSQL: Odoo's ORM manages recordsets, caching, transactions, and database interaction.
Integration layer: APIs, webhooks, scheduled jobs, or middleware connect external systems.
Infrastructure layer: Linux, PostgreSQL, reverse proxy, workers, backups, monitoring, and deployment automation.

Odoo's current developer documentation specifically recommends batching record operations, reducing algorithmic complexity, and using indexes selectively. Its profiler also provides SQL and periodic collectors for locating database and Python bottlenecks.

That matters because an implementation decision can become a runtime problem. A method that performs one database query per record may appear acceptable with 100 records but behave very differently when the same workflow processes thousands.

Odoo Implementation Services: An Architecture-First Approach

Step 1: Model the business workflow before customizing Odoo

The first step in Odoo Implementation Services is deciding which requirements belong to configuration, existing modules, custom modules, or external integrations.

For example, an order workflow might be represented as:

Sales → Inventory → Delivery → Invoice → Payment

Before writing Python, define:

Which model owns each business object?
Which events change its state?
Which users can perform each transition?
Which external system is the source of truth?
Which operations must be transactional?
Which tasks can run asynchronously?

This prevents custom modules from duplicating functionality already provided by Odoo's ORM and standard modules.

Step 2: Design database access around recordsets

The second step in Odoo Implementation Services is controlling database query volume.

Odoo maintains record caches and uses prefetching to avoid repeatedly querying individual fields. A common mistake is breaking that batching behavior inside loops.

Instead of repeatedly querying related records, collect the IDs and perform one grouped operation:

def _compute_order_count(self):
    # Why: one grouped query is preferable to one query per order.
    data = self.env["sale.order"]._read_group(
        [("partner_id", "in", self.ids)],
        ["partner_id"],
        ["__count"],
    )

    counts = {partner.id: count for partner, count in data}

    for partner in self:
        # Why: dictionary lookup avoids another database query.
        partner.order_count = counts.get(partner.id, 0)

Odoo's documentation presents batching as a core performance practice and recommends grouped operations instead of executing SQL-producing methods repeatedly inside record loops.

For frequently filtered custom fields, an index can also help:

reference = fields.Char(
    index=True,  # Why: accelerates frequent equality/search operations.
)

Indexes should not be added indiscriminately because they consume storage and add overhead to writes.

Step 3: Separate synchronous transactions from background work

The third step in Odoo Implementation Services is deciding what should happen during the user's HTTP request.

A user confirming an order needs an immediate transaction result. Generating thousands of downstream records, synchronizing an external catalog, or processing historical data may not belong in the same request.

For scheduled operations, Odoo recommends processing work in batches rather than allowing a single cron execution to occupy a worker for an extended period.

The trade-off is complexity. Background processing requires retry handling, idempotency, monitoring, and failure recovery. However, putting every operation into the request lifecycle can create long response times and worker contention.

Real-World Application

In one of our Odoo Implementation Services projects at Oodles, Virbac India required a centralized planning platform covering sales forecasting, production planning, and procurement. The implementation used Odoo to connect forecasting, production targets, raw-material requirements, stock levels, and Bills of Materials, with role-based access and audit controls. The system worked with five years of historical sales data, making data modeling and planning workflows important architectural concerns.

The measurable scope included multiple planning functions, automated production scheduling, raw-material gap analysis, purchase recommendations, and audit tracking rather than relying on disconnected spreadsheets.

In another Oodles implementation, Green Energy Africa required accounting, inventory, POS, attendance, and WhatsApp integration. Oodles also provided five days of departmental training alongside configuration and integration work. Python and SQL were used for scripting and database-related integration tasks.

You can explore more engineering and implementation work from Oodles.

Key Takeaways

Odoo Implementation Services should start with workflow and data modeling, not custom screens.
Batch ORM operations to control database query growth as record volume increases.
Add PostgreSQL indexes only to fields that justify their read-performance benefit.
Keep long-running processing outside latency-sensitive user transactions where appropriate.
Treat permissions, integration contracts, retries, auditing, and deployment as architecture concerns rather than post-launch tasks.

If you are designing a new Odoo architecture, migrating an existing ERP, or dealing with performance and integration constraints, share your technical scenario in the comments. For a deeper implementation discussion, contact us about Odoo Implementation Services through Odoo Implementation Services.

FAQ

What are Odoo Implementation Services?

Odoo Implementation Services cover the technical and functional work required to configure, customize, integrate, test, deploy, and support an Odoo ERP system. The scope can include module configuration, Python development, PostgreSQL setup, third-party APIs, data migration, access control, testing, deployment, and user training.

Should custom Odoo modules replace standard Odoo functionality?

No. Custom modules should be introduced when configuration or existing Odoo modules cannot satisfy a documented requirement. Keeping standard functionality where possible reduces custom-code ownership and makes future upgrades easier to manage.

How can Odoo performance be improved?

Odoo performance can be improved by batching ORM operations, avoiding unnecessary queries inside loops, selecting appropriate database indexes, reducing algorithmic complexity, and profiling SQL and Python execution. Odoo provides built-in SQL and periodic profiling collectors for identifying performance bottlenecks.

When should an Odoo workflow use background processing?

Background processing is appropriate for work that is long-running, non-interactive, or independently retryable, such as bulk synchronization, large imports, report generation, or scheduled data processing. User-facing transactions should generally remain focused on operations that require an immediate result.

Can Odoo integrate with external business systems?

Yes. Odoo can integrate with external systems through APIs and other integration mechanisms. For example, Oodles integrated Odoo with ShipHero using custom APIs to synchronize orders and automatically apply delivery and pickup costs.

Agentic AI Development Services: How to Build Reliable Tool-Using AI Agents

Naresh Chandra Lohani — Wed, 26 Aug 2026 07:09:18 +0000

An AI agent becomes difficult to operate when it can do more than generate text. Once an agent can call APIs, query databases, update records, invoke other agents, or trigger workflows, a single failed tool call can create duplicate actions, inconsistent state, or an execution loop.

This is where Agentic AI Development Services need to go beyond prompt engineering. The engineering problem is building a controlled runtime around the model: explicit tools, durable state, validation, retries, permissions, and traces. This guide shows a practical architecture using Node.js-style services, structured tool calls, Redis or a database for state, and an observability layer. For teams evaluating an implementation partner, see agentic AI development services from Oodles.

Context and Setup

The right architecture treats an agent as an application component, not as an autonomous black box.

A typical workflow looks like this:

User Request
     |
     v
API Gateway
     |
     v
Agent Orchestrator
     |
     +----> LLM
     |
     +----> Tool Registry
     |         |
     |         +--> CRM
     |         +--> Database
     |         +--> Search
     |         +--> Internal APIs
     |
     +----> State Store
     |
     +----> Observability

The orchestrator owns execution. The LLM proposes the next action, but application code decides whether that action is valid and permitted.

This distinction matters because AI adoption is high while confidence in AI output remains comparatively low. The 2025 Stack Overflow Developer Survey reports that 84% of respondents are using or planning to use AI tools, while 46% distrust the accuracy of AI output compared with 33% who trust it. Among developers building agents, Grafana plus Prometheus were used by 43% for observability.

For production systems, that makes validation and telemetry first-class engineering concerns.

Agentic AI Development Services Architecture

The core implementation should separate reasoning from execution. Agentic AI Development Services work best when the model has bounded capabilities and the runtime controls every external side effect.

Step 1: Define bounded tools

Start by converting business operations into explicit tools.

A tool should have:

A stable name.
A strict input schema.
A clearly defined permission boundary.
A deterministic response structure.
An explicit failure contract.

For example, instead of allowing an agent to "manage customer accounts," expose narrowly scoped operations such as findCustomer, getOrder, and createSupportTicket.

This reduces the blast radius of an incorrect model decision. AWS's Agentic AI Lens similarly recommends specialized agents with explicit scope and authority rather than large, unrestricted agents.

Step 2: Put validation between the model and the tool

Never send raw model output directly to an external system.

The application should parse the requested action, validate its schema, check authorization, and only then execute it.

async function executeToolCall(call, user) {
  // Why: reject malformed model output before it reaches business systems.
  const tool = toolRegistry.get(call.name);

  if (!tool) {
    throw new Error("Unknown tool");
  }

  // Why: authorization belongs to application code, not the LLM.
  await authorize(user, tool.requiredPermission);

  // Why: schema validation prevents unsafe or incomplete arguments.
  const args = tool.schema.parse(call.arguments);

  // Why: every execution receives a trace ID for debugging.
  return tool.execute(args, { traceId: call.traceId });
}

This pattern also makes testing easier. Tool execution can be unit-tested independently from the model.

Step 3: Make retries and state idempotent

Retries are necessary because agents depend on networks, APIs, databases, queues, and model providers. But retrying a non-idempotent operation can create duplicate side effects.

Consider an agent that creates an invoice. If the API succeeds but the response is lost, the agent may retry the same operation. Without an idempotency key, two invoices could be created.

Use a deterministic key derived from the workflow and operation:

const crypto = require("crypto");

function createIdempotencyKey(workflowId, operation, payload) {
  // Why: identical retries must produce the same key.
  return crypto
    .createHash("sha256")
    .update(`${workflowId}:${operation}:${JSON.stringify(payload)}`)
    .digest("hex");
}

Before executing a side-effecting operation, check whether the key already exists. AWS specifically recommends deterministic idempotency keys, conditional writes, and propagation of those keys through multi-step workflows.

This is preferable to generating a new UUID for every retry because a new UUID makes the retry look like a completely different operation.

Step 4: Trace every decision and tool call

Agent logs should answer more than "did the API return 500?"

For each execution, capture:

Workflow ID.
Agent ID and version.
Model and configuration.
Tool selected.
Validated arguments.
Tool latency.
Tool result status.
Retry count.
Token usage and estimated cost.
Final outcome.

AWS recommends distributed traces that include agent invocations, tool calls, memory operations, and inter-agent handoffs.

This also changes how incidents are debugged. Instead of reconstructing a conversation from application logs, engineers can follow one workflow across the model, queue, database, and downstream services.

Real-World Application

In one of our Agentic AI Development Services projects at Oodles, we built a multi-agent conversational intelligence platform for AalmostHuman.ai. The system combined Dialogue, Workflow, Knowledge, Compliance, Translation, and Insight agents with contextual memory, RAG, CRM and ITSM integrations, and omnichannel communication.

The architecture had to support real-time voice and chat interactions while coordinating multiple specialized agents. Oodles implemented real-time speech processing and reported low-latency interactions below 300ms, alongside multilingual translation and enterprise integrations with Salesforce, Zendesk, and ServiceNow.

The important architectural lesson is that the latency target was not treated as an LLM-only problem. Agent boundaries, context retrieval, backend integrations, and real-time processing all had to participate in the execution design.

You can explore more engineering work from Oodles, including AI agents, RAG systems, workflow automation, and enterprise integrations.

Conclusion / Key Takeaways

Separate reasoning from execution: the model proposes actions while application code validates and executes them.
Use bounded tools: narrow capabilities make permissions, testing, and failure handling easier to control.
Design retries around idempotency: a retry should never accidentally become a second business transaction.
Persist workflow state: checkpointed execution allows an agent to resume from a known state instead of restarting the entire workflow.
Trace agent behavior end to end: model calls, tool invocations, state changes, and downstream requests should share a trace context.

Building an agent that works in a demo is different from operating one against production systems. If your architecture involves multi-agent orchestration, enterprise APIs, RAG, workflow automation, or real-time interactions, discuss the execution model before choosing the framework.

Have you encountered duplicate tool execution, runaway agent loops, or difficult-to-debug agent workflows? Share the failure mode in the comments.

For a technical discussion about Agentic AI Development Services, connect with the Oodles engineering team.

FAQ

What are Agentic AI Development Services?

Agentic AI Development Services involve engineering AI agents that can reason about tasks, select approved tools, maintain state, and execute multi-step workflows. Production implementations typically include orchestration, tool validation, permissions, observability, retry handling, and integration with enterprise systems.

How is an AI agent different from a chatbot?

A chatbot primarily generates conversational responses, while an AI agent can execute actions through defined tools. For example, a chatbot can explain an order status, whereas an agent can retrieve the order, update a support ticket, and trigger an approved workflow.

How should AI agents handle failed API calls?

AI agents should classify failures before retrying. Transient failures can use bounded retries with exponential backoff and jitter, while authorization, validation, or business-rule failures should normally stop execution or trigger a fallback. AWS recommends staged recovery, retry budgets, and distributed tracing for agent systems.

Why is idempotency important for AI agents?

Idempotency prevents repeated execution from creating duplicate side effects. If an agent retries an invoice, payment, or database mutation after an uncertain network response, a deterministic idempotency key lets the application recognize the previous operation and safely return its existing result.

When should a company use Agentic AI Development Services?

A company should consider Agentic AI Development Services when AI needs to perform controlled multi-step work across business systems rather than only generate text. Suitable use cases include IT automation, customer operations, research workflows, data analysis, support ticket processing, and enterprise process orchestration.

How a CRM Software Development Company Can Design Idempotent Webhook Pipelines with Node.js and AWS

Naresh Chandra Lohani — Tue, 25 Aug 2026 03:17:32 +0000

A CRM API can look fast in development and still fail under production traffic when the same lead arrives twice, webhook events are delivered out of order, or a downstream service times out after committing a database transaction. These failures are common in CRM systems because integrations sit between multiple systems with different retry and consistency rules.

A CRM Software Development Company building such systems should treat event delivery as an infrastructure problem, not simply an API integration task. In this guide, we will design a Node.js and AWS-based pipeline using PostgreSQL, Redis, Docker, and asynchronous workers. For broader CRM architecture patterns, see Oodles CRM application development services.

Context and Setup

The system receives lead, contact, opportunity, and activity events from external applications. A typical flow looks like:

CRM/Webhook → API Gateway → Node.js API → Queue → Worker → PostgreSQL/Redis → External integrations

The important property is that the HTTP endpoint should acknowledge the event quickly while processing happens asynchronously.

This matters because AWS recommends a data-driven approach to performance efficiency and specifically recommends benchmarking, monitoring, caching, load testing, and selecting architecture based on workload characteristics.

For the database layer, PostgreSQL is also a practical choice for CRM workloads. Stack Overflow's 2024 Developer Survey reported that almost 50% of professional developers surveyed used PostgreSQL, highlighting its continued adoption among professional development teams.

Designing the Webhook Pipeline with a CRM Software Development Company

The key design decision is simple: never assume a webhook is delivered exactly once.

Step 1: Create an Idempotency Boundary

The first step is to assign every external event a unique identifier.

For example:

event_id = "ghl_9f72a1"
event_type = "lead.created"
source = "crm"

Store the event ID before processing business logic. A unique database constraint prevents two workers from processing the same event concurrently.

CREATE TABLE webhook_events (
    event_id VARCHAR(255) PRIMARY KEY,
    event_type VARCHAR(100) NOT NULL,
    received_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Why this matters: a CRM provider can retry a webhook when it does not receive an acknowledgement quickly. Without an idempotency boundary, one customer interaction can create duplicate leads, activities, or notifications.

Step 2: Separate Ingestion from Processing

The webhook endpoint should validate the request, persist the event, enqueue work, and return.

app.post("/webhooks/crm", async (req, res) => {
  const { eventId, type, payload } = req.body;

  await db.query(
    `INSERT INTO webhook_events(event_id, event_type)
     VALUES ($1, $2)
     ON CONFLICT (event_id) DO NOTHING`,
    [eventId, type] // Prevents duplicate event insertion.
  );

  await queue.send({
    eventId,
    type,
    payload
  }); // Why: moves slow work outside the request lifecycle.

  res.status(202).json({ accepted: true });
});

The worker then performs enrichment, database updates, notifications, and third-party API calls.

This architecture also makes failure recovery easier. If an external API becomes unavailable, the worker can retry without forcing the original webhook sender to wait.

AWS documentation recommends loosely coupled components, controlled retries, client timeouts, and asynchronous patterns when designing distributed systems.

Step 3: Add Caching Without Breaking Consistency

CRM applications frequently read the same information repeatedly: account details, sales-owner mappings, configuration, pipeline stages, and permission data.

Redis can reduce repeated database reads, but cache invalidation must be explicit.

const key = `account:${accountId}`;

let account = await redis.get(key);

if (!account) {
  account = await db.getAccount(accountId);

  await redis.set(
    key,
    JSON.stringify(account),
    "EX",
    300 // Why: five-minute TTL limits stale configuration data.
  );
}

Caching should not become the source of truth. AWS specifically recommends caching access patterns that benefit from faster retrieval while warning against treating cache data as durable storage.

For a CRM Software Development Company, the practical trade-off is consistency versus read performance. Customer balances, permissions, and transaction state generally need stronger consistency than static configuration or frequently viewed dashboard summaries.

Real-World Application

In one of our CRM-related projects at Oodles, the team worked on a CRM-integrated conversational system where the requirement included real-time synchronization with GoHighLevel CRM and function calls based on user intent. The architecture used ReactJS and Python and was designed to reduce manual operations while improving campaign responsiveness.

The important engineering lesson was not simply connecting a chatbot to a CRM. The integration had to coordinate conversational intent, CRM state, API calls, and workflow execution without turning the user-facing request into a chain of blocking operations.

Oodles also documents a separate production system where content chunking and prompt engineering brought conversational response time to about 2 seconds. That project used LangChain, ChatGPT, Twilio, Google Speech-to-Text, and Stripe. While it was not the CRM implementation, it illustrates the same architectural principle: isolate expensive processing and measure the actual response path rather than optimizing individual functions in isolation.

You can explore more engineering work from Oodles.

Key Takeaways

Idempotency belongs at the ingestion boundary, before CRM business logic starts.
Webhook handlers should acknowledge quickly and move expensive work to asynchronous workers.
Database constraints are part of concurrency control, not merely data validation.
Redis should accelerate reads, not replace PostgreSQL as the source of truth.
Performance optimization should be measurement-driven, using latency, queue depth, cache hit rate, database timings, and external API duration.

Building a CRM integration requires more than connecting REST endpoints. The difficult engineering work appears around retries, duplicate events, consistency, observability, authentication, rate limits, and failure recovery.

If you are designing a CRM backend, dealing with webhook duplication, or deciding between synchronous and event-driven integration, share your architecture or question in the comments.

For a technical discussion with a CRM Software Development Company, contact CRM Software Development Company.

FAQ

1. How do I prevent duplicate CRM webhook events?

Use an idempotency key supplied by the CRM provider and enforce a unique constraint in your database. Store the event before processing business logic, then safely ignore repeated deliveries with the same event ID.

2. Should CRM webhooks be processed synchronously?

Usually, no. The webhook endpoint should validate and enqueue the event, then return an acknowledgement. A worker can perform enrichment, database updates, notifications, and external API calls asynchronously, reducing timeout risk and improving failure recovery.

3. Why use Redis in CRM application architecture?

Redis is useful for frequently requested, reconstructable data such as configuration, permissions metadata, or dashboard aggregates. A CRM Software Development Company should define TTL and invalidation rules because cached data can become stale.

4. Is PostgreSQL suitable for CRM systems?

Yes. PostgreSQL supports relational CRM entities, transactions, constraints, indexing, JSON data, and complex queries. Its transactional model is particularly useful when creating related records such as contacts, activities, opportunities, and audit entries.

5. How should CRM integrations handle external API failures?

Use bounded retries with exponential backoff, request timeouts, idempotent operations, and a dead-letter mechanism. Do not retry indefinitely because a persistent downstream failure can otherwise create queue growth and duplicate side effects.

ERPNext Implementation Services: A Developer’s Guide to Production Architecture and Performance

Naresh Chandra Lohani — Sun, 23 Aug 2026 23:58:10 +0000

A common ERPNext production problem starts innocently: a transaction works correctly in development, but response times increase when users generate reports, import records, or trigger scheduled jobs at the same time. The issue is rarely ERPNext alone. It usually comes from how the Frappe application layer, MariaDB, Redis, workers, and custom code are configured.

This is where ERPNext Implementation Services need to go beyond installing ERPNext. A production implementation should define application boundaries, background processing, database strategy, deployment automation, observability, and upgrade practices from the beginning. Teams evaluating ERPNext implementation services should therefore treat implementation as an engineering problem rather than a configuration exercise.

Context and Setup

ERPNext runs on the Frappe Framework, a Python and JavaScript full-stack framework. A typical deployment includes the Frappe application server, MariaDB, Redis, background workers, scheduler processes, and NGINX. Frappe also uses the concept of a bench as a deployment unit, while individual sites have isolated databases.

For developers, this architecture creates an important design boundary:

Synchronous requests handle operations that users must see immediately.
Background workers handle expensive operations such as large reports and bulk processing.
Redis provides caching and queue infrastructure.
MariaDB remains the primary transactional data store.
NGINX and application processes handle incoming web traffic.

The distinction matters because Frappe's documentation notes that background jobs keep web workers available for other requests instead of allowing long-running operations to consume request resources.

There is also a broader reason to keep the stack maintainable. The 2025 Stack Overflow Developer Survey reported a 7 percentage-point increase in Python adoption from 2024 to 2025. For engineering teams, that makes Python-based customization easier to support across a wider developer ecosystem.

Designing ERPNext Implementation Services for Production

Step 1: Separate User Requests From Heavy Work

The first optimization is architectural: do not make the HTTP request responsible for work that can safely happen asynchronously.

Suppose an ERPNext customization needs to process 50,000 inventory records. Executing that operation inside the user's request can consume an application worker for an extended period.

Frappe provides frappe.enqueue() for this exact pattern, with short, default, and long queues available for different workloads.

import frappe

def process_inventory():
    # Why: expensive processing should not block the user's HTTP request.
    update_inventory_records()

def start_inventory_sync():
    # Why: the worker handles the operation asynchronously.
    frappe.enqueue(
        "my_app.inventory.process_inventory",
        queue="long"
    )

The important engineering decision is not simply using a queue. It is classifying workloads correctly. User-facing validation should remain synchronous. Large imports, reconciliation, report generation, and scheduled processing are better candidates for workers.

Step 2: Make Database Access Deliberate

The second step is controlling database pressure.

A poorly designed custom report can repeatedly query large tables, fetch unnecessary fields, or perform database operations inside loops. As transaction volume increases, MariaDB can become the limiting component.

A better pattern is to retrieve only the required fields and move repeated, relatively static lookups into cache where appropriate.

import frappe

def get_company_settings(company):
    # Why: avoids repeating the same database lookup during a request.
    cache_key = f"company_settings:{company}"

    cached = frappe.cache.get_value(cache_key)
    if cached:
        return cached

    settings = frappe.db.get_value(
        "Company",
        company,
        ["default_currency", "country"],
        as_dict=True
    )

    # Why: cached data reduces repeated database work.
    frappe.cache.set_value(cache_key, settings)

    return settings

Frappe provides Redis-backed caching specifically for repeated computations and data that does not change frequently.

For ERPNext Implementation Services, database design should therefore include query profiling, index review, report optimization, and cache boundaries rather than treating MariaDB as an unlimited resource.

Step 3: Design Deployment Around the Bench

The third step is establishing a repeatable deployment model.

A development environment may run everything on one machine. Production requirements can be different. Frappe documentation describes separate application servers, database servers, Redis, background workers, NGINX, and file storage as independently scalable components.

A practical deployment sequence is:

Build the custom application as a version-controlled Frappe app.
Pin compatible framework and application versions.
Create isolated staging and production sites.
Automate migrations and asset builds.
Run database backups before upgrades.
Monitor web requests, queues, database load, and scheduled jobs.
Validate customizations against the target ERPNext/Frappe version before production rollout.

Docker can also be introduced when reproducible environments and infrastructure portability are priorities. Frappe's installation documentation specifically points production and Docker-based development users toward frappe_docker.

The trade-off is operational complexity. A single-server deployment is simpler and may be appropriate for a smaller workload. Separating application, database, and worker capacity makes more sense when workload patterns require independent scaling.

Real-World Application

In one of our ERPNext implementation services engagements at Oodles, the engineering focus should be framed around measurable workload characteristics rather than generic infrastructure sizing. For an implementation involving transactional workflows, custom reports, integrations, and scheduled processing, the practical engineering sequence is to baseline API latency, identify expensive queries, move long-running operations to queues, and retest under representative concurrency.

Rather than publishing an unverified project metric, the useful benchmark for your own implementation is a before-and-after measurement such as:

API p50 and p95 response time
Database query duration
Queue wait time
Background-job execution time
Concurrent user capacity
Failed or retried jobs

This measurement-first approach is also consistent with Frappe's architecture: application workers, database resources, Redis, and background workers can be analyzed separately instead of treating the entire ERP system as one performance unit.

You can review the engineering capabilities behind these implementations at Oodles.

Conclusion: Key Takeaways

Move expensive operations to background workers so HTTP workers remain available for interactive requests.
Profile MariaDB queries before scaling infrastructure, because inefficient queries can remain bottlenecks even after adding application capacity.
Use Redis selectively for repeated reads and computations where cache invalidation is well defined.
Treat customizations as version-controlled applications, not isolated production edits.
Benchmark p50, p95, queue latency, and database performance before and after major architectural changes.

Have a specific ERPNext performance, customization, migration, or deployment problem? Share the architecture and bottleneck in the DEV.to comments, and we can discuss possible implementation patterns.

For a technical discussion about ERPNext Implementation Services, contact Oodles.

FAQ

What are ERPNext Implementation Services?

ERPNext Implementation Services cover the technical work required to configure, customize, integrate, deploy, test, secure, and maintain an ERPNext environment. For engineering teams, this can include Frappe app development, database optimization, integrations, background jobs, deployment automation, and upgrade planning.

Is ERPNext suitable for custom business workflows?

Yes. ERPNext is built on Frappe, which supports custom applications, DocTypes, server-side Python logic, JavaScript interfaces, APIs, permissions, background jobs, and scheduled tasks. This allows teams to implement business-specific workflows without modifying every part of the ERPNext core.

How should long-running ERPNext operations be handled?

Long-running operations should generally be moved to Frappe background workers instead of keeping users waiting on HTTP requests. Frappe provides frappe.enqueue() and multiple queues, including short, default, and long, for asynchronous processing.

Can ERPNext scale beyond a single server?

Yes. Frappe's architecture allows application servers, database resources, Redis, background workers, NGINX, and file storage to be separated and scaled according to workload. The appropriate design depends on concurrency, transaction volume, reporting load, integration traffic, and operational requirements.

What should developers measure during ERPNext Implementation Services?

Developers should measure API p50 and p95 latency, database query duration, queue wait time, background-job execution time, error rates, and resource utilization. These metrics establish a baseline and make it possible to verify whether an optimization actually improves production behavior.

CRM Software Development Services: Designing a Fast, Integration-Ready CRM with Node.js and AWS

Naresh Chandra Lohani — Fri, 21 Aug 2026 02:09:42 +0000

A CRM API can work perfectly at 20 requests per second and still become a bottleneck when sales activity, automation, reporting, and third-party integrations start sharing the same database. The usual failure point is not the UI. It is synchronous workflows that make every request wait on multiple downstream systems.

This article explains an architecture for CRM Software Development Services focused on API performance, asynchronous processing, caching, and integration boundaries. For teams building custom CRM platforms rather than configuring an off-the-shelf product, the goal is to keep business workflows responsive while preserving data consistency. You can also review Oodles' custom CRM development approach for examples of CRM implementations across different operational workflows.

Context and Setup

The architecture assumes a CRM with contacts, leads, accounts, deals, activities, reporting, authentication, and external integrations.

A practical baseline looks like this:

Web / Mobile Clients
        |
   API Gateway
        |
   Application API
   /           \
CRM Database   Redis
   |
Message Queue
   |
Workers -> CRM / ERP / Messaging / External APIs

The key architectural decision is separating user-facing transactions from work that does not need to finish before the HTTP response.

This matters because CRM operations frequently trigger secondary actions:

Creating a lead
Updating an account
Sending notifications
Synchronizing an external CRM
Recalculating sales metrics
Writing audit events
Updating search indexes

Stack Overflow's 2024 Developer Survey received responses from more than 65,000 developers overall, with PostgreSQL remaining a leading database choice among professional developers.

For a relational CRM, PostgreSQL is a reasonable starting point because relationships between contacts, accounts, deals, activities, and users are central to the data model.

Designing CRM Software Development Services for API Performance

The solution is to make the synchronous API path deliberately small and move expensive operations outside it.

Step 1: Separate Transactional and Background Work

The first step is identifying what the user actually needs to receive before the request completes.

For example, when a sales representative creates a lead, the API should primarily validate and persist the lead. Sending an email, synchronizing another platform, and rebuilding analytics should not necessarily block that request.

A simplified Node.js service might look like this:

async function createLead(payload) {
  // Why: validate before opening a database transaction.
  const lead = validateLead(payload);

  // Why: the lead itself must be durable before publishing follow-up work.
  const savedLead = await leadRepository.create(lead);

  // Why: downstream integrations do not need to delay the HTTP response.
  await queue.publish("lead.created", {
    leadId: savedLead.id
  });

  return savedLead;
}

The important boundary is lead.created. Consumers can independently handle email, CRM synchronization, analytics, or notifications.

This also makes failures easier to isolate. If an external API is temporarily unavailable, the lead creation transaction does not have to fail with it.

Step 2: Add Caching Around Read-Heavy CRM Queries

CRM dashboards are commonly read-heavy. Users may repeatedly request pipeline summaries, user permissions, account details, or configuration data that changes less frequently than it is read.

AWS recommends identifying data sources with heavy read workloads and applying caching where appropriate, while explicitly considering expiration and consistency.

A Redis-backed cache can be introduced at the service layer:

async function getPipeline(userId) {
  const key = `pipeline:${userId}`;

  // Why: avoid hitting PostgreSQL for repeated dashboard requests.
  const cached = await redis.get(key);

  if (cached) return JSON.parse(cached);

  const pipeline = await repository.getPipeline(userId);

  // Why: short TTL limits stale dashboard data.
  await redis.set(key, JSON.stringify(pipeline), { EX: 30 });

  return pipeline;
}

Do not cache every CRM object. Customer records, permissions, and deal states can have different freshness requirements.

AWS specifically warns that caching requires attention to consistency, expiration, and monitoring rather than treating cached data as permanent storage.

Step 3: Choose Queues Over Long Synchronous Chains

The third step is introducing asynchronous workers when a CRM operation has multiple downstream effects.

For example:

POST /leads
     |
     +--> PostgreSQL
     |
     +--> lead.created
             |
             +--> Email Worker
             +--> CRM Sync Worker
             +--> Analytics Worker
             +--> Notification Worker

This approach is preferable to calling four external APIs sequentially from the controller.

The trade-off is eventual consistency. A user may see a newly created lead immediately while an external integration updates a few seconds later.

That is acceptable when the UI clearly represents synchronization status.

For stronger delivery guarantees, store the event in an outbox table within the same database transaction, then publish it through a worker. This prevents the classic failure where the database commit succeeds but the message publish fails.

Real-World Application

In one of our CRM-related projects at Oodles, Champion Cash Loans required lead capture automation connecting a PHP website, Zoho CRM, a Java-based vehicle pricing API, and AWS infrastructure. Oodles implemented automatic lead submission into Zoho CRM, a custom CRM function that triggered the pricing service, and a Spring Boot API that returned vehicle pricing data for updating CRM records. The application was deployed using Docker on AWS.

The measurable architectural outcome here is the elimination of manual handoffs across four infrastructure components: the lead website, Zoho CRM, pricing API, and AWS deployment environment. The public case study does not publish latency figures, so inventing a before-and-after response-time number would be misleading.

This type of integration is representative of the engineering problems that matter in CRM Software Development Services: defining ownership of data, controlling API dependencies, handling retries, and deciding which operations belong inside or outside the request lifecycle.

For more examples of Oodles' engineering work, visit Oodles.

Conclusion: Key Takeaways

Keep CRM write transactions focused on durable business state.
Move notifications, synchronization, analytics, and other secondary work to asynchronous workers.
Cache read-heavy dashboard queries with explicit TTL and consistency rules.
Use an outbox pattern when database commits and message delivery must remain reliable.
Measure API latency, queue depth, cache hit rate, database load, and external API failures separately.

Have a CRM architecture problem involving API integrations, database scaling, asynchronous workflows, or multi-system synchronization? Share your architecture or question in the comments.

For a technical discussion about CRM Software Development Services, contact Oodles.

FAQ

1. What are CRM Software Development Services?

CRM Software Development Services cover the engineering of custom customer relationship platforms, including data models, APIs, authentication, workflows, dashboards, automation, integrations, reporting, and cloud deployment. The architecture can be built around business-specific processes instead of forcing those processes into a fixed CRM structure.

2. Should a CRM use microservices?

Not necessarily. A modular monolith is often simpler for an early CRM because contacts, accounts, deals, and permissions have strong transactional relationships. Services can be separated later when independent scaling, deployment, ownership, or integration boundaries justify the additional operational complexity.

3. How can CRM API performance be improved?

Reduce database round trips, optimize indexes and queries, paginate large datasets, cache suitable read-heavy operations, and move non-critical work to background workers. AWS also recommends caching appropriate access patterns to reduce database pressure and improve read latency.

4. Is Redis suitable for CRM applications?

Redis is suitable for frequently accessed, reconstructable data such as dashboard summaries, configuration, short-lived sessions, and rate-limit counters. It should not become the authoritative store for customer or deal records. Cache expiration and invalidation rules should match each CRM data type.

5. What should CRM Software Development Services include for third-party integrations?

A production CRM integration should include authentication, request validation, retry policies, rate-limit handling, timeout controls, idempotency, webhook processing, audit logging, and synchronization status. External API failures should be isolated so a temporary integration outage does not corrupt core CRM transactions.