SRE

 SRE  Components

1. Open Telemetry (OTel) is open-source observability framework to generate and transport observability metrics, logs, traces (e2e)
2. MDPL (Monitoring Data PipeLine)  Long term metrics store : Collect and stores the monitoring/observability key metrics data. (Typically, Prometheus)
3. SingleView : It is Grafana as solution. It visualizes the observability data collected. 
4. SLING : Reporting the SLI

Splunk is monitoring & observability platform that collect, store, analyze and visualize data from applications, infra, network and security systems

Synthetic monitoring or proactive monitoring  is website monitoring that is done using a Web browser emulation or scripted recordings of Web transactions. Example: Splunk

Traditional PegaApp (or manual Rule-Application) as Constellation app

 1. Open Rule-Application, set pyIsConstellationApp=true, pxUseDXAPI=true. Save the app record.

2. Execute pzRegisterConstellationAppAsOAuth2Client in the context of Rule-Applicaiton.

3. It should create oAuth client registration record.

Database indexes

Index unique scan

It occurs when the db looks up a single unique row and is able to stop searching the very instant that row is found. No sequential reading.

Two strict requirements - A unique constraint exists (PK, Unique), An equality operator is used. 

Index range scan

 Accesses a continuous segment of pre-sorted index entries using leading columns.

The database locates the starting value in an index and reads consecutive leaf blocks sequentially until it hits the upper boundary of the range

Requires the query's WHERE clause to reference the leading (leftmost) column of a composite index

Best used for range operators (BETWEEN, <,>,>=,<=) or equality conditions (=) on primary prefix of the index.  (works well if the first column in the index where clause applied with equality check, and rest with ranges)

Highly efficient and selective when fetching small percentage of total table rows

Index skip scan

The database finds distinct values of the omitted leading column and performs a separate mini-range scan for each distinct prefix value.

Triggers on a composite index even when the leading column is missing from the WHERE clause

Best used for composite indexes where the leading column has low cardinality (very few distinct values like gender, status_code..etc) and subsequent columns are well-filtered.

Can prevent expensive full table scans, but can degrade performance significantly if the skipped leading column has high cardinality because it multiplies the number of internal lookups.

Index full scan

An index full scan is a DB operation where the system reads every single block of a B-tree index from start to finish in sorted key order.

When and shy it is used? Avoiding sorts : (1) The optimizer chooses an index full scan when a query has an ORDER BY or GROUP BY clause that matches the sorted columns in the index. (2) If all the columns requested by the query exist inside the index, the db can process the entire request without touching the main base table

Kafka vs REST

 

REST API = synchronous request-response communication.

Kafka = asynchronous event streaming/message broker.

Throughput

Suppose you need to process 100,000 transactions per second.

REST

Every request:

• Opens/uses connection
• Executes logic
• Returns response

The API server becomes the bottleneck.

Kafka

Messages are:

• Batched
• Sequentially written to disk
• Consumed independently

Kafka is designed for extremely high throughput.

Winner for throughput:

✅ Kafka

Example:

• Website clickstream events
• Telemetry data
• IoT sensor data
• Log aggregation

Scalability

REST

Scaling often means:

• More API instances
• Load balancers
• Database scaling

All consumers hit the same API.

Kafka

You can independently scale:

• Producers
• Brokers
• Consumer groups

If traffic doubles:

• Add more consumers
• Rebalance partitions

Winner:

✅ Kafka

Reliability Under Load

REST

If a downstream service is unavailable:

• Requests timeout
• Retries increase load
• Cascading failures may occur

Kafka

Messages remain in the broker:

• Consumers can be offline
• Processing resumes later
• No message loss (with proper configuration)

Winner:

✅ Kafka

Fan-Out Performance

Suppose an order event must be consumed by:

• Billing service
• Inventory service
• Analytics service
• Notification service

REST

Order Service
    |
    |--> Billing API
    |--> Inventory API
    |--> Analytics API
    |--> Notification API

Many network calls.

Kafka

Order Service --> Kafka Topic

Billing Consumer
Inventory Consumer
Analytics Consumer
Notification Consumer

Single publish, many consumers.

Winner:

✅ Kafka

Resource Usage

REST

Good for:

• Interactive user operations
• CRUD applications
• Real-time queries

Kafka

Good for:

• Massive event streams
• Decoupled microservices
• Event sourcing
• Data pipelines

Aspect	REST API	Kafka
Communication	Synchronous	Asynchronous
Latency	Very low (milliseconds) for direct request	Slightly higher end-to-end due to broker hop
Throughput	Limited by API server capacity	Extremely high (millions of messages/sec possible)
Scalability	Scale API servers horizontally	Scale producers, brokers, and consumers independently
Reliability	Client retries required	Built-in persistence and replay
Backpressure handling	Difficult	Native consumer lag handling
Fan-out to multiple consumers	Multiple API calls needed	Publish once, consume many times
Real-time response	Excellent	Not ideal for immediate response

Pega dirty dialog

 Dirty Dialog - Troubleshooting | Support Center

Theme cosmos : Shareable links

 https://forums.pega.com/t/theme-cosmos-open-work-object-in-full-portal-on-copy-sharable-link/635

AI Prompts

 Build out the content for this agent instructions file for this project. This is an instructions file specifically for the LLM's to adhere to the coding standards for this project. Agent instructions will be separated out into separate .md markdown files localted in the /docs directory