Hi! I'm

Federico Calò

Software Developer | Technical Writer

I create modern web applications and custom digital tools to help businesses grow through technological innovation. My passion is combining computer science and economics to generate real value.

Contact Me

About Me

My passion for computer science was born at the Technical Commercial Institute of Maglie, where I discovered the power of programming and the fascination of creating digital solutions. From the start, I understood that computer science was not just code, but an extraordinary tool for turning ideas into reality.

During my studies in Business Information Systems, I began to interweave computer science and economics, understanding how technology can be the engine of growth for any business. This vision accompanied me to the University of Bari, where I obtained my degree in Computer Science, deepening my technical skills and passion for software development.

Today I put this experience at the service of businesses, professionals and startups, creating tailor-made digital solutions that automate processes, optimize resources and open new business opportunities. Because true innovation begins when technology meets the real needs of people.

My Skills

Data Analysis & Predictive Models

I transform data into strategic insights with in-depth analysis and predictive models for informed decisions

Process Automation

I create custom tools that automate repetitive operations and free up time for value-added activities

Custom Systems

I develop tailor-made software systems, from platform integrations to customized dashboards

const federico = {
  nome: "Federico Calò",
  ruolo: "Sviluppatore Software",
  città: "Bari, Italia",
  missione: "Aiutare attraverso l'informatica",
  passioni: [
    "Codice Pulito",
    "Innovazione",
    "Crescita Continua"
  ]
};

La Mia Missione

Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.

🚀

Democratizzare la Tecnologia

La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.

💡

Unire Informatica ed Economia

Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.

🎯

Creare Soluzioni su Misura

Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.

Trasforma la Tua Attività con la Tecnologia

December 2024

View

Master SQL

RoadMap.sh

Novembre 2024

View

Oracle Certified Foundations Associate

Oracle

October 2024

View

People Leadership Credential

Connect

Settembre 2024

💻 Languages & Technologies

☕Java

🐍Python

📜JavaScript

🅰️Angular

⚛️React

🔷TypeScript

🗄️SQL

🐘PHP

🎨CSS/SCSS

🔧Node.js

🐳Docker

🌿Git

💼

12/2024 - Presente

Custom Software Engineering Analyst

Accenture

Bari, Puglia, Italia · Ibrida Analisi e sviluppo di sistemi informatici attraverso l'utilizzo di Java e Quarkus in Health and Public Sector. Formazione continua su tecnologie moderne per la creazione di soluzioni software personalizzate ed efficienti e sugli agenti.

💼

06/2022 - 12/2024

Analista software e Back End Developer Associate Consultant

Links Management and Technology SpA

Esperienza nell'analisi di sistemi software as-is e flussi ETL utilizzando PowerCenter. Formazione completata su Spring Boot per lo sviluppo di applicazioni backend moderne e scalabili. Sviluppatore Backend specializzato in Spring Boot, con esperienza in progettazione di database, analisi, sviluppo e testing dei task assegnati.

💼

02/2021 - 10/2021

Programmatore software

Adesso.it (prima era WebScience srl)

Esperienza nell'analisi AS-IS e TO-BE, evoluzioni SEO ed evoluzioni website per migliorare le performance e l'engagement degli utenti.

🎓

2018 - 2025

Laurea in Informatica

Università degli Studi di Bari Aldo Moro

Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.

📚

2013 - 2018

Diploma - Sistemi Informativi Aziendali

Istituto Tecnico Commerciale di Maglie

Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.

Contattami

Hai un progetto in mente? Parliamone! Compila il form qui sotto e ti risponderò al più presto.

* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.

CQRS: Separate Read and Write for Independent Scaling

A classic REST API uses the same model to read and write data. But the needs reading and writing are often very different: writes must guarantee consistency and validate complex business rules; reads must be fast, scalable, and return data in UI-optimized formats. Try to satisfy both needs with it same model leads to compromises: complex queries for views, or "bloated" models to support any type of reading.

CQRS (Command Query Responsibility Segregation) explicitly separates the writing model (command side) from the reading model (query side). The command side manages operations that change the state (create, update, delete); the query side handles read operations, typically with optimized data models for specific application views. Synchronization between the two occurs via asynchronous events or projections.

What You Will Learn

CQRS architecture: command side, query side, asynchronous synchronization
Implement a Command Handler in TypeScript with validation
Projections: build Read Models optimized for views
Asynchronous synchronization via events (Event Sourcing + CQRS)
CQRS without Event Sourcing: Simplified hybrid model
Independent read and write scaling
Trade-off: possible consistency and operational complexity

CQRS architecture

In CQRS, each operation is or a Command (change status) or one Queries (reads the state without modifying it). Never both at the same time method (Bertrand Meyer's CQS principle):

// WRONG: un metodo che fa sia command che query
async function reserveInventory(productId: string, quantity: number): Promise<Stock> {
  const stock = await db.getStock(productId);
  stock.reserved += quantity;  // MODIFICA
  await db.saveStock(stock);
  return stock;  // LETTURA
}

// RIGHT CQRS: separa command e query
async function reserveInventory(productId: string, quantity: number): Promise<void> {
  // Command: solo modifica, nessun ritorno di stato
  const stock = await stockRepo.findById(productId);
  stock.reserve(quantity);
  await stockRepo.save(stock);
  // Pubblica evento per aggiornare il read model
  await eventBus.publish(new InventoryReservedEvent(productId, quantity));
}

async function getStockLevel(productId: string): Promise<StockLevelDto> {
  // Query: legge dal read model ottimizzato, ZERO side effects
  return await stockReadModel.findById(productId);
}

The Command Side: Command Management

The command side receives Command (immutable objects that describe an intention), li valid, executes business logic on the Aggregate, and publishes events. The pattern Command Handler and the component that coordinates this flow:

// ---- COMMANDS ----
// Ogni command e un DTO immutabile
class PlaceOrderCommand {
  constructor(
    public readonly orderId: string,
    public readonly customerId: string,
    public readonly items: ReadonlyArray<{
      productId: string;
      quantity: number;
    }>,
    public readonly shippingAddress: Readonly<Address>
  ) {}
}

// ---- COMMAND HANDLER ----
class PlaceOrderCommandHandler {
  constructor(
    private readonly orderRepo: OrderRepository,
    private readonly productRepo: ProductRepository,
    private readonly eventBus: EventBus
  ) {}

  async handle(command: PlaceOrderCommand): Promise<void> {
    // 1. Validazione: prodotti esistono?
    const products = await Promise.all(
      command.items.map((item) => this.productRepo.findById(item.productId))
    );
    if (products.some((p) => p === null)) {
      throw new Error('One or more products not found');
    }

    // 2. Crea l'Aggregate (logica business)
    const order = new OrderAggregate();
    order.create(command.orderId, command.customerId);

    for (let i = 0; i < command.items.length; i++) {
      const product = products[i]!;
      order.addItem(
        command.items[i].productId,
        command.items[i].quantity,
        product.price
      );
    }
    order.confirm();

    // 3. Persisti gli eventi generati dall'Aggregate
    await this.orderRepo.save(order);

    // 4. Pubblica gli eventi per aggiornare il read model e notificare altri servizi
    const events = order.getUncommittedEvents();
    await this.eventBus.publishAll(events);
  }
}

// ---- COMMAND BUS ----
// Dispatcher che instrada i command all'handler corretto
class CommandBus {
  private handlers = new Map<string, (cmd: unknown) => Promise<void>>();

  register<T>(commandType: string, handler: (cmd: T) => Promise<void>): void {
    this.handlers.set(commandType, handler as (cmd: unknown) => Promise<void>);
  }

  async dispatch<T>(commandType: string, command: T): Promise<void> {
    const handler = this.handlers.get(commandType);
    if (!handler) {
      throw new Error(`No handler registered for command: ${commandType}`);
    }
    await handler(command);
  }
}

// Setup
const commandBus = new CommandBus();
commandBus.register('PlaceOrder', (cmd: PlaceOrderCommand) =>
  placeOrderHandler.handle(cmd)
);

The Query Side: Read Model and Projections

The query side maintains a Read Model: a representation of the data optimized for specific application queries. While the command side works with the Aggregate, the query side works with denormalized views constructed via Projections.

// ---- READ MODEL ----
// Viste denormalizzate ottimizzate per le query dell'UI

// View per la lista ordini: include dati del cliente + totale + stato
interface OrderListItemReadModel {
  orderId: string;
  customerName: string;         // denormalizzato (non serve join)
  customerEmail: string;
  totalAmount: number;
  currency: string;
  status: string;
  itemCount: number;
  placedAt: string;
}

// View per il dettaglio ordine
interface OrderDetailReadModel {
  orderId: string;
  customerId: string;
  customerName: string;
  items: Array<{
    productId: string;
    productName: string;        // denormalizzato
    quantity: number;
    unitPrice: number;
    subtotal: number;
  }>;
  totalAmount: number;
  shippingAddress: Address;
  status: string;
  statusHistory: Array<{ status: string; changedAt: string }>;
  estimatedDelivery?: string;
}

// ---- PROIEZIONE ----
// Aggiorna il read model in risposta agli eventi del command side
class OrderReadModelProjection {
  constructor(
    private readonly readModelDb: ReadModelDatabase,
    private readonly customerRepo: CustomerReadRepository
  ) {}

  // Quando un ordine viene confermato, crea/aggiorna le view nel read model
  async onOrderConfirmed(event: OrderConfirmedEvent): Promise<void> {
    // Carica i dati aggiuntivi necessari per la view denormalizzata
    const customer = await this.customerRepo.findById(event.customerId);
    const orderState = await this.orderRepo.findById(event.orderId);

    // Inserisce/aggiorna la view della lista ordini
    await this.readModelDb.upsert('order_list_view', {
      order_id: event.orderId,
      customer_name: customer.fullName,
      customer_email: customer.email,
      total_amount: orderState.totalAmount,
      currency: orderState.currency,
      status: 'Confirmed',
      item_count: orderState.items.size,
      placed_at: orderState.createdAt,
    });

    // Inserisce la view di dettaglio
    const itemsWithNames = await this.enrichItemsWithProductNames(orderState.items);
    await this.readModelDb.upsert('order_detail_view', {
      order_id: event.orderId,
      // ... tutti i campi della view dettaglio
      items: JSON.stringify(itemsWithNames),
      status_history: JSON.stringify([
        { status: 'Confirmed', changedAt: event.occurredAt }
      ]),
    });
  }

  async onOrderCancelled(event: OrderCancelledEvent): Promise<void> {
    // Aggiorna solo lo status nella view
    await this.readModelDb.update('order_list_view',
      { order_id: event.orderId },
      { status: 'Cancelled' }
    );
    // Aggiungi alla status history nella view dettaglio
    await this.readModelDb.appendToJsonArray('order_detail_view',
      { order_id: event.orderId },
      'status_history',
      { status: 'Cancelled', changedAt: event.occurredAt }
    );
  }
}

// ---- QUERY HANDLER ----
class OrderQueryHandler {
  constructor(private readonly readModelDb: ReadModelDatabase) {}

  // Query velocissima sul read model denormalizzato
  async getOrderList(customerId: string, page: number, pageSize: number):
    Promise<OrderListItemReadModel[]>
  {
    return this.readModelDb.query(
      `SELECT * FROM order_list_view
       WHERE customer_id = $1
       ORDER BY placed_at DESC
       LIMIT $2 OFFSET $3`,
      [customerId, pageSize, page * pageSize]
    );
  }

  async getOrderDetail(orderId: string): Promise<OrderDetailReadModel | null> {
    return this.readModelDb.queryOne(
      'SELECT * FROM order_detail_view WHERE order_id = $1',
      [orderId]
    );
  }
}

CQRS without Event Sourcing

CQRS and Event Sourcing are orthogonal: they work well together, but they can be used separately. The simplified CQRS model without Event Sourcing uses the database main database for writes and a separate database (or materialized views) for reads:

// CQRS semplificato: stesso database, modelli separati
// Write side usa le entita ORM normali
// Read side usa query SQL ottimizzate o viste materializzate

// View materializzata PostgreSQL per la lista ordini
CREATE MATERIALIZED VIEW order_list_view AS
SELECT
  o.id AS order_id,
  c.full_name AS customer_name,
  c.email AS customer_email,
  o.total_amount,
  o.currency,
  o.status,
  COUNT(oi.id) AS item_count,
  o.created_at AS placed_at
FROM orders o
JOIN customers c ON c.id = o.customer_id
LEFT JOIN order_items oi ON oi.order_id = o.id
GROUP BY o.id, c.full_name, c.email;

-- Refresh automatico della vista materializzata
CREATE INDEX idx_order_list_customer ON order_list_view (customer_email);

-- Con PostgreSQL 17: INCREMENTAL REFRESH (solo le righe cambiate)
-- REFRESH MATERIALIZED VIEW CONCURRENTLY order_list_view;

-- Query sul read model: 100x piu veloce di una query con JOIN
SELECT * FROM order_list_view
WHERE customer_email = 'mario@example.com'
ORDER BY placed_at DESC
LIMIT 20;

Independent Scaling Read and Write

With CQRS, you can scale the read side and write side independently. If the system has 100x more reads than writes (typical for an e-commerce), you can have:

Write side: 2 instances with PostgreSQL primary database
Read side: 10 instances with Redis cache + read-only PostgreSQL replication

// Architettura di scaling con Kubernetes
# command-side-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-command-service
spec:
  replicas: 2   # write side: pochi ma consistenti
  template:
    spec:
      containers:
        - name: api
          image: company/order-service:v1
          env:
            - name: DB_URL
              value: "postgres://primary-db:5432/orders"  # database primario
            - name: SERVICE_MODE
              value: "command"
---
# query-side-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-query-service
spec:
  replicas: 10  # read side: molte repliche, stateless
  template:
    spec:
      containers:
        - name: api
          image: company/order-service:v1
          env:
            - name: DB_URL
              value: "postgres://read-replica:5432/orders"  # replica read-only
            - name: REDIS_URL
              value: "redis://cache:6379"
            - name: SERVICE_MODE
              value: "query"

Manage Eventual Consistency in the Frontend

In CQRS with asynchronous synchronization, there is a short period (typically milliseconds) where the read model is not yet updated after a write. The frontend has to handle this correctly:

// Pattern 1: Optimistic Update
// Il frontend aggiorna l'UI immediatamente, senza aspettare la query
async function placeOrder(orderData: PlaceOrderDto) {
  // 1. Ottimisticamente aggiorna l'UI locale
  dispatch({ type: 'ADD_ORDER_OPTIMISTIC', order: { ...orderData, status: 'Pending' } });

  try {
    // 2. Invia il command al backend
    const response = await api.placeOrder(orderData);

    // 3. Dopo N ms, ricarica dal read model (che dovrebbe essere aggiornato)
    setTimeout(async () => {
      const updatedOrder = await api.getOrder(response.orderId);
      dispatch({ type: 'UPDATE_ORDER', order: updatedOrder });
    }, 500);

  } catch (error) {
    // 4. In caso di errore, reverta l'ottimistic update
    dispatch({ type: 'REVERT_ORDER_OPTIMISTIC' });
    throw error;
  }
}

// Pattern 2: Poll finche il read model non e aggiornato
async function pollUntilUpdated(orderId: string, expectedStatus: string) {
  const MAX_ATTEMPTS = 10;
  const DELAY_MS = 200;

  for (let i = 0; i < MAX_ATTEMPTS; i++) {
    const order = await api.getOrder(orderId);
    if (order.status === expectedStatus) return order;
    await new Promise(resolve => setTimeout(resolve, DELAY_MS));
  }
  throw new Error('Read model not updated within expected time');
}

CQRS trade-off

Benefits

Independent scaling: Read side and write side scale separately based on actual load
Optimized templates: The read model can be denormalized exactly for the view, eliminating complex queries
High read performance: Queries on the read model are simple SELECTs on pre-computed tables
Separation of responsibilities: Write and read code do not contaminate each other

Complex to Manage

Possible consistency: The read model may lag slightly behind the writes. The frontend has to handle it
Logic Duplication: Some validations may need to be in both the command handler and the read model
More components to deploy: Command service, query service, projections, read model database
Not suitable for simple CRUD: The complexity of CQRS is not worth it for operations without complex business logic

Conclusions and Next Steps

CQRS is one of the most effective architectures for systems with read and write loads very different. The explicit separation of the command side (consistent, validated, event-driven) from the query side (fast, denormalized, scalable) solves the trade-offs of the single model.

The next article combines Event Sourcing and CQRS together: we will see how the projections they read from the event store to build the read model, how to manage projections with retry in case of error, and how to use snapshots to optimize the rebuild of the read model after a failure.

Upcoming Articles in the Event-Driven Architecture Series

Related Series

Event Sourcing — the natural complement of CQRS
Practical Software Architecture — where to place CQRS in the context of the overall architecture